News for hackers. Stuff that matters.

A comment on If it's a nice problem to have, don't solve it now.

Re:If it's a nice problem to have, don't solve it now by frandroid on Monday August 10, 2020 @12:44PM (#24111224)
The problem with issues like this is that this is patch development. If you don't look a couple steps ahead and at least think through your "nice to have" problems, you might end up getting the architecture wrong. The password reset problem might drive you to find an authentication library instead of rolling your own. Suddenly, your "nice to have" problem is fixed before you get to it, because you decided to look at the larger picture instead of just rushing to just rely on an email and password column in your MVP. That way when you demo your app to an investor or early beta users, you won't be stuck saying "oh, there's no password reset, just create another one".
[ Parent | on HN ]
Re:If it's a nice problem to have, don't solve it now by OJFord on Monday August 10, 2020 @12:58PM (#24111400)
My instinct is to agree with you, but with my practical instinct-taming hat on, I reckon you could have between thousands and tens of thousands of monthly active users (depending on demographic - how likely they are to need reset) before taking a phone call to reset it manually in db would be burdensome.

And between 0 and that many users you could have all sorts of other reasons for rethinking your authentication architecture, nevermind whether home grown or third-party library.

[ Parent | on HN ]
Re:If it's a nice problem to have, don't solve it now by munificent on Monday August 10, 2020 @12:52PM (#24111316)
This is a great point. It's important to be mindful of the path dependence you are creating for your future self. At any point in time, I think you can roughly bucket problems into three categories:

1. This is a blocking issue now.

2. This is not a block issue now, but postponing will cause more pain than we would save by not doing it now.

3. This is not a blocking issue and doesn't create future pain.

The third bucket are natural to postpone. Finding the balance between the first two is one of the primary challenges of engineering.

[ Parent | on HN ]
Re:If it's a nice problem to have, don't solve it now by afarrell on Tuesday August 11, 2020 @06:52AM (#24119049)
I think there is a 4th category: This is not an obviously blocking issue right now, but it creates enough mental load that it prevents my work from being rewarding.
[ Parent | on HN ]
Re:If it's a nice problem to have, don't solve it now by dakiol on Monday August 10, 2020 @12:53PM (#24111327)
I'm curious, what's the right alternative to having an email and password columns in a "customers" table?
[ Parent | on HN ]
Re:If it's a nice problem to have, don't solve it now by twiss on Monday August 10, 2020 @01:20PM (#24111661)
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.
[ Parent | on HN ]
Re:If it's a nice problem to have, don't solve it now by tonyarkles on Monday August 10, 2020 @01:53PM (#24111996)
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).
[ Parent | on HN ]
Re:If it's a nice problem to have, don't solve it now by dakiol on Monday August 10, 2020 @01:30PM (#24111759)
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.
[ Parent | on HN ]
Re:If it's a nice problem to have, don't solve it now by twiss on Monday August 10, 2020 @01:36PM (#24111824)
No, that's fine :) It wasn't clear to me from your original comment whether you were hashing passwords, apologies.
[ Parent | on HN ]
Re:If it's a nice problem to have, don't solve it now by frandroid on Tuesday August 11, 2020 @03:49AM (#24118138)
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.

[ Parent | on HN ]
Re:If it's a nice problem to have, don't solve it now by abraae on Tuesday August 11, 2020 @12:39AM (#24117209)
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.

[ Parent | on HN ]
Re:If it's a nice problem to have, don't solve it now by john-shaffer on Monday August 10, 2020 @01:05PM (#24111488)
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.

[ Parent | on HN ]
Re:If it's a nice problem to have, don't solve it now by hinkley on Monday August 10, 2020 @12:54PM (#24111337)
Definitely.

People who think their problems are small or simple write their own libraries, and then every change in requirements gets incorporated into the library or blamed on the victim. By the time the system is profitable you've reimplemented half of a robust library, badly.

[ Parent | on HN ]