4 ms·

I'm curious, what's the right alternative to having an email and password columns in a "customers" table?

by dakiol 6y ago

john-shaffer 6y ago
As one example, Django's auth framework gives you a users table which it manages. You would set a foreign key column from customers to users. I believe the point of GP was to say "use an auth framework". If you're rolling your own auth, then your approach is fine.
twiss 6y ago
In addition to the sibling answer of "use a framework"; if you simply stick passwords in a database, and the database gets stolen, you've now leaked your users' passwords. So you should hash the passwords, and they should be salted, so now you need a `salt` column. Most people use too cheap a hash function, so this is an additional argument for using a library / framework.
- dakiol 6y ago
  Umm, but using bcrypt to hash the passwords is just a couple of lines of code (at least in Go); I'm wondering if I'm doing things wrong by not using a dedicated framework.
  - twiss 6y ago
    No, that's fine :) It wasn't clear to me from your original comment whether you were hashing passwords, apologies.
- tonyarkles 6y ago
  As a minor nit, most salted password hash algorithms store the salt at the start (usually) or end (occasionally) of the hash, so you don't need a separate column. You end up with two functions: one to generate a new password hash (which securely generates a salt as well), and one to compare a plain-text password with the (salt+hash).
abraae 6y ago
One alternative is to use something like Keycloak or some other auth tech. Then you'll have password recovery, 2FA, sign in with FB/Goog/LinkedIn etc., loads of insightful management screens and even SAML support for enterprise SSO - all free, out of the box, battle-hardened and already in wide use with many eyes on it for security. Then when your customer waves some IT checklist in front of you asking you "do you support blah blah password complexity" the answer is just YES. The TFA has a solid point, but has picked a bad example to illustrate it. These days if you find yourself even thinking about building your own password recovery, even way off in the future, you should really reexamine your core decisions.
frandroid 6y ago
Cognito is a popular auth service that's used by many people who want to launch an MVP on AWS, for example. You would not keep the password yourself at that point. Later on you might realize that you've bound your user ID to email and that you need to use UUID, where email is just a contact address. You might even want to have users have multiple accounts that use the same email address. You might decide to bind the user's account to their phone number instead. It's not about One True Strategy, but about looking further into what you will need in the future. You might decide not to develop something right away, but you can avoid much refactoring later by making a smart decision now that did not involve any more work than the less smart decision.

I'm curious, what's the right alternative to having an email and password columns in a "customers" table?

by dakiol 6y ago

I'm curious, what's the right alternative to having an email and password columns in a "customers" table?

As one example, Django's auth framework gives you a users table which it manages. You would set a foreign key column from customers to users. I believe the point of GP was to say "use an auth framework". If you're rolling your own auth, then your approach is fine.

twiss 6y ago

In addition to the sibling answer of "use a framework"; if you simply stick passwords in a database, and the database gets stolen, you've now leaked your users' passwords. So you should hash the passwords, and they should be salted, so now you need a `salt` column. Most people use too cheap a hash function, so this is an additional argument for using a library / framework.

dakiol 6y ago
Umm, but using bcrypt to hash the passwords is just a couple of lines of code (at least in Go); I'm wondering if I'm doing things wrong by not using a dedicated framework.
- twiss 6y ago
  No, that's fine :) It wasn't clear to me from your original comment whether you were hashing passwords, apologies.
tonyarkles 6y ago
As a minor nit, most salted password hash algorithms store the salt at the start (usually) or end (occasionally) of the hash, so you don't need a separate column. You end up with two functions: one to generate a new password hash (which securely generates a salt as well), and one to compare a plain-text password with the (salt+hash).

abraae 6y ago

One alternative is to use something like Keycloak or some other auth tech. Then you'll have password recovery, 2FA, sign in with FB/Goog/LinkedIn etc., loads of insightful management screens and even SAML support for enterprise SSO - all free, out of the box, battle-hardened and already in wide use with many eyes on it for security. Then when your customer waves some IT checklist in front of you asking you "do you support blah blah password complexity" the answer is just YES. The TFA has a solid point, but has picked a bad example to illustrate it. These days if you find yourself even thinking about building your own password recovery, even way off in the future, you should really reexamine your core decisions.

frandroid 6y ago

Cognito is a popular auth service that's used by many people who want to launch an MVP on AWS, for example. You would not keep the password yourself at that point. Later on you might realize that you've bound your user ID to email and that you need to use UUID, where email is just a contact address. You might even want to have users have multiple accounts that use the same email address. You might decide to bind the user's account to their phone number instead. It's not about One True Strategy, but about looking further into what you will need in the future. You might decide not to develop something right away, but you can avoid much refactoring later by making a smart decision now that did not involve any more work than the less smart decision.