4 ms·

Well, in this particular case passwords are always hashed. So the platform deals with that for you. Other changes to the data model need a migration, which is c

Well, in this particular case passwords are always hashed. So the platform deals with that for you. Other changes to the data model need a migration, which is covered here: https://alan-platform.com/pages/tuts/migration.html https://alan-platform.com/pages/tuts/migration.html

WorkLifeBalance 8y ago
Where is the definition of the password being hashed? The tutorial defines it as text: /* 'Users': collection { 'Password': text }*/ How does the platform know to hash that? Is it looking for magic property names?
- klageveen 8y ago
  No, there is no magic :) When you set up the users at the top of the model file, you specify which property is the password.
  - WorkLifeBalance 8y ago
    Specifying something as password hashing as (sha256? salted sha256?) without telling it to seems like magic to me. So to clarify, it's this password: declaration which tells the framework to hash the input? users dynamic : . 'Users' password : . 'Password' interfaces root { } numerical-types Is this defined anywhere within the project or is this framework magic? (Or "glue" if you don't like the term magic). password is not mentioned again anywhere in the documentation, I'd like to understand how the framework knows to hash the input.
    - klageveen 8y ago
      The line `password : . 'Password'` points at the password property, which tells the framework to hash it. What kind of hashing isn't something you should have to specify or worry about. It's a strong salted hash and we'd like to make it even better at some point, but that's firmly in the realm of the framework implementation.
      - TheOtherHobbes 8y ago
        This parses to "Just trust us to get this right." I think you may have some issues persuading customers that's a wholly valid approach, especially when you're dealing with security and data integrity, GDPR, and so on.
CodesInChaos 8y ago
It looks like you're using SHA256(username||password) in this example. Even if it's only an example, why use a homebrew password hashing scheme based on an unsuitable hash function and bad ad-hoc salt handling, instead of a strong standard password hash with built in salt handling? And what code/specification is required to use a secure algorithm, like bcrypt with a random salt? People often copy from such tutorials and will then end up with insecure password storage.
- byproxy 8y ago
  As someone who's not a developer but still occasionally looks through these "build an app" tutorials, password/authentication portions always worry me. I wish I could know that best-practices were shown as far as storing/encrypting user data/passwords.

WorkLifeBalance 8y ago

Where is the definition of the password being hashed? The tutorial defines it as text: /* 'Users': collection { 'Password': text }*/ How does the platform know to hash that? Is it looking for magic property names?

klageveen 8y ago
No, there is no magic :) When you set up the users at the top of the model file, you specify which property is the password.
- WorkLifeBalance 8y ago
  Specifying something as password hashing as (sha256? salted sha256?) without telling it to seems like magic to me. So to clarify, it's this password: declaration which tells the framework to hash the input? users dynamic : . 'Users' password : . 'Password' interfaces root { } numerical-types Is this defined anywhere within the project or is this framework magic? (Or "glue" if you don't like the term magic). password is not mentioned again anywhere in the documentation, I'd like to understand how the framework knows to hash the input.
  - klageveen 8y ago
    The line `password : . 'Password'` points at the password property, which tells the framework to hash it. What kind of hashing isn't something you should have to specify or worry about. It's a strong salted hash and we'd like to make it even better at some point, but that's firmly in the realm of the framework implementation.
    - TheOtherHobbes 8y ago
      This parses to "Just trust us to get this right." I think you may have some issues persuading customers that's a wholly valid approach, especially when you're dealing with security and data integrity, GDPR, and so on.

CodesInChaos 8y ago

It looks like you're using SHA256(username||password) in this example. Even if it's only an example, why use a homebrew password hashing scheme based on an unsuitable hash function and bad ad-hoc salt handling, instead of a strong standard password hash with built in salt handling? And what code/specification is required to use a secure algorithm, like bcrypt with a random salt? People often copy from such tutorials and will then end up with insecure password storage.

byproxy 8y ago
As someone who's not a developer but still occasionally looks through these "build an app" tutorials, password/authentication portions always worry me. I wish I could know that best-practices were shown as far as storing/encrypting user data/passwords.