5 ms·

I've seen something like this before that allowed login with any password as long as you gave a valid user name: > if (hash(password == hashedPassword)) { logi

I've seen something like this before that allowed login with any password as long as you gave a valid user name: > if (hash(password == hashedPassword)) { login(username); } "Don't write your own hash function" is common advice, but I would go much further and say don't write anything to do with passwords, logins, roles or sessions etc. if you can because one small mistake is all it takes to create a huge security hole.

debarshri 6y ago
It really depends what kind of product you are building. Sometimes, especially an enterprise product, monolithic in nature, you have to building user management, session management, role management into the product. It does take a seasoned engineer to do to so. But lot of these concepts are well established. I would say dont write your own hash function, dont create your own concepts in user, role and session management.
- samus 6y ago
  Enterprises with a significant number of IT services are well-adviced to think about consolidation of authentication and authentication mechanisms. There is a huge zoo of architectures to choose from (LDAP/AD, Kerberos, OAuth, Radius, OpenID) and most off-the-shelf software has integrations for these. Every password that your users have to remember increases the chance that they use unsafe ones or even write them down on sticky notes on their desktop. Yes, middlewares have bugs too, but most of the trivial ones likely have been found long ago.
jedimastert 6y ago
Does anyone have any experience with password-less login? Like were you just do the other half of a 2fa like an email? And I mean both experience as a consumer or developer. I feel like if I were to have a service that required log in that's how I would do it, but with all the talking about it I've never actually seen it in the wild.
- bobbylarrybobby 6y ago
  Until recently, this was the only login method supported by non-Google Notion accounts.
- NovemberWhiskey 6y ago
  I have seen a 'trusted links' concept in production: imagine you have news stories (or similar) behind a paywall. You send out emails to your customers with direct story links that include a token which bypasses the paywall. Optionally, have that link log the user in a low-trust context where step-up auth is required to do e.g. account management.
- gen3 6y ago
  This is how Hack Club Bank works. You enter your email, then wait for the 6 digit code emailed to you. No passwords at all.
mnutt 6y ago
The best part there is that even the intended code is probably insecure, since == will likely open you to timing attacks and should be replaced with a secure comparison function.
- jpab 6y ago
  Unless it's also a non-cryptographic hash then I don't see how a timing attack does anything interesting here. Timing will potentially tell you how many bytes of the hash match. But finding a password that produces a hash that matches the first N bytes does not help you find a password that matches the N+1th byte, so you're still just left with a brute force attack. What am I missing? (Genuinely curious - I'm not a crypto expert)
  - aliceryhl 6y ago
    As long as the system isn't written such that only the hash is necessary to log in, it should be fine to just compare hashes normally.
mercer 6y ago
I disagree. Authentication and authorization are central to many areas in which programmers work. And while there are plenty of gotchas (especially in webdev perhaps), at it's core it can be learned, understood, and implemented right as long as you rely on the experts for the proper tricky bits ("don't roll your own crypto") Sure, if you can outsource authentication to FB or Apple or OAuth, then that's great. But even then you're still on your own when it comes to authorization. And it's still important to understand what these services are doing for you. So in the end you still need to properly grok both authentication and authorization. One of the big 'milestones' in my career was finally building something that involved logins, roles, sessions, etc. It scared the crap out of me from all the HN stuff I'd read. In the end, despite all the gotchas in browser-land in particular, it turned out to not be as complicated as I thought, or at least the complications involved things that no 3rd party service could take care of for me.
- rtlfe 6y ago
  > It scared the crap out of me from all the HN stuff I'd read. Probably that's why you were successful. Lots of people make mistakes because they don't understand how important it is.
- wonderlg 6y ago
  Great, but “don’t roll your own auth” should still be the default. I’ve seen far too many awful login systems at any level that I’d really prefer if NO ONE rolled their own, especially no single unsupervised developer.
  - doublerabbit 6y ago
    > I’d really prefer if NO ONE rolled their own I really disagree with this. How do you learn about encryption, security et cetera if you don't do it yourself? It would be like removing the letter B from ABC because the letter B may be unsafe.
Can_Not 6y ago
> don't write anything to do with passwords, logins, roles or sessions etc I'll take this a step further and say don't push anything important to production that isn't covered by tests.

debarshri 6y ago

It really depends what kind of product you are building. Sometimes, especially an enterprise product, monolithic in nature, you have to building user management, session management, role management into the product. It does take a seasoned engineer to do to so. But lot of these concepts are well established. I would say dont write your own hash function, dont create your own concepts in user, role and session management.

samus 6y ago
Enterprises with a significant number of IT services are well-adviced to think about consolidation of authentication and authentication mechanisms. There is a huge zoo of architectures to choose from (LDAP/AD, Kerberos, OAuth, Radius, OpenID) and most off-the-shelf software has integrations for these. Every password that your users have to remember increases the chance that they use unsafe ones or even write them down on sticky notes on their desktop. Yes, middlewares have bugs too, but most of the trivial ones likely have been found long ago.

jedimastert 6y ago

Does anyone have any experience with password-less login? Like were you just do the other half of a 2fa like an email? And I mean both experience as a consumer or developer. I feel like if I were to have a service that required log in that's how I would do it, but with all the talking about it I've never actually seen it in the wild.

bobbylarrybobby 6y ago
Until recently, this was the only login method supported by non-Google Notion accounts.
NovemberWhiskey 6y ago
I have seen a 'trusted links' concept in production: imagine you have news stories (or similar) behind a paywall. You send out emails to your customers with direct story links that include a token which bypasses the paywall. Optionally, have that link log the user in a low-trust context where step-up auth is required to do e.g. account management.
gen3 6y ago
This is how Hack Club Bank works. You enter your email, then wait for the 6 digit code emailed to you. No passwords at all.

mnutt 6y ago

The best part there is that even the intended code is probably insecure, since == will likely open you to timing attacks and should be replaced with a secure comparison function.

jpab 6y ago
Unless it's also a non-cryptographic hash then I don't see how a timing attack does anything interesting here. Timing will potentially tell you how many bytes of the hash match. But finding a password that produces a hash that matches the first N bytes does not help you find a password that matches the N+1th byte, so you're still just left with a brute force attack. What am I missing? (Genuinely curious - I'm not a crypto expert)
- aliceryhl 6y ago
  As long as the system isn't written such that only the hash is necessary to log in, it should be fine to just compare hashes normally.

mercer 6y ago

I disagree. Authentication and authorization are central to many areas in which programmers work. And while there are plenty of gotchas (especially in webdev perhaps), at it's core it can be learned, understood, and implemented right as long as you rely on the experts for the proper tricky bits ("don't roll your own crypto") Sure, if you can outsource authentication to FB or Apple or OAuth, then that's great. But even then you're still on your own when it comes to authorization. And it's still important to understand what these services are doing for you. So in the end you still need to properly grok both authentication and authorization. One of the big 'milestones' in my career was finally building something that involved logins, roles, sessions, etc. It scared the crap out of me from all the HN stuff I'd read. In the end, despite all the gotchas in browser-land in particular, it turned out to not be as complicated as I thought, or at least the complications involved things that no 3rd party service could take care of for me.

rtlfe 6y ago
> It scared the crap out of me from all the HN stuff I'd read. Probably that's why you were successful. Lots of people make mistakes because they don't understand how important it is.
wonderlg 6y ago
Great, but “don’t roll your own auth” should still be the default. I’ve seen far too many awful login systems at any level that I’d really prefer if NO ONE rolled their own, especially no single unsupervised developer.
- doublerabbit 6y ago
  > I’d really prefer if NO ONE rolled their own I really disagree with this. How do you learn about encryption, security et cetera if you don't do it yourself? It would be like removing the letter B from ABC because the letter B may be unsafe.

Can_Not 6y ago

> don't write anything to do with passwords, logins, roles or sessions etc I'll take this a step further and say don't push anything important to production that isn't covered by tests.