If this were a tech interview and you had ever had a job in industry on your resume, I would likely end consideration of you a candidate and switch to mentor mode to help you understand what to study before your next interview (at a different company). I dislike when developers insist on “not invented here” mentality and anything concerning security should not be an excuse to reinvent the wheel and make the same mistakes a million other developers already made.
Auth is ridiculously complex, is the source of MANY critical security defects, has plenty of frameworks which solve significant parts of it, and always seems easy until someone explains to you what all you didn’t know you needed.
Components:
- login page
- two factor state
- password reset form
- username lookup form
- logic for 401 status
- logic for 403 status
- throttling, is ban, user lockouts, and/or captchas for the forms you don’t want attacked at scale
- if you are storing credentials on your server (like password hashes), you better know what the options are for hashes, what a salt is, have investigated bcrypt and scrypt, know what happened when any of the thousands of large websites had their user databases leaked
- maybe support warning users that their credentials in your DB matches a record in HaveIBeenPwned and lock down their account until they password reset using their email address
- have a plan for when the hash you chose is deprecated in a few years while you aren’t paying attention and need to spent days re-coding to support new hash and legacy hash users, auto-migrating the legacies on next login
- want to support multiple 3rd party IDPs as well as local password auth? That starts to explode complexity and the number of forms.
- want to support SSO for enterprise? Use a framework that already supports SAML integration
There are roughly 3 phases in your career. In the first, you don't know much and do things simply, naively. In the second, you know quite a lot, and like it or not you will be quite attached to your own expertise, it will be part of your identity. Your solutions tend to be complex, but you believe they must be that way, and you have evidence this is so. In the third phase, you begin to perceive systems as ephemeral results of some causal chain, and have a sense of how they became the way that they are. This depth of understanding allows you to embrace simplicity again, but this time you understand precisely the limits of that complexity.
I think a lot of professionals (not just programmers) get stuck in phase 2. This is where, in our field, most of the code comes from: capable, smart people writing new code furiously, and with the not incosequential fact that it provably works. Sure, it has bugs, but you can get to those eventually. It also happens to be the most "defensible" phase, where you get to speak down to others - you have concrete experience, real knowledge, so you are justified. I would guess this is also the bulk of working programmers.
So, the OP's solution could be coming from a phase 1 or phase 3 place. You are certainly coming from phase 2. I would encourage you to stretch a bit and consider when the OP's simple solution makes sense, and when it doesn't. I would hope you would do this in an interview as well, because you'll find phase 3 people saying all kinds of whacky things, which might not make sense to you unless you ask.
(A careful phase 3 will make sure to preface his simple solution with his limits, and to not do so is a little bit sloppy, but personally I don't think that's a deal-breaker.)
Fair enough, but if you have reached phase 3, you would undoubtedly know that Auth logic is fairly complex and rolling your own half baked solution will put your users at risk?
I can't think of a situation where OP's solution makes sense. Except for the obvious cases (app will never be in production, will never have real users or contain valuable data, etc)
The OPs soln makes sense for an intranet application with a small-ish user base (e.g. an internal app used by startup personnel) In this case, the likelihood of threat models like brute-force attacks, XSS, etc are all dwarfed by other threat models (social, physical, etc). I think it's a good compromise; and at least they aren't storing passwords in the clear, and picked a good hash function! These are really low-hanging fruit and you'd be surprised how often even this goes wrong.
In any event, I also believe there is a generally better approach to auth that avoids a lot of the complexity of traditional approaches. It's speculative, but see my other comment in this thread: https://news.ycombinator.com/item?id=22157951
Comments
If this were a tech interview and you had ever had a job in industry on your resume, I would likely end consideration of you a candidate and switch to mentor mode to help you understand what to study before your next interview (at a different company). I dislike when developers insist on “not invented here” mentality and anything concerning security should not be an excuse to reinvent the wheel and make the same mistakes a million other developers already made.
Auth is ridiculously complex, is the source of MANY critical security defects, has plenty of frameworks which solve significant parts of it, and always seems easy until someone explains to you what all you didn’t know you needed.
Components:
- login page
- two factor state
- password reset form
- username lookup form
- logic for 401 status
- logic for 403 status
- throttling, is ban, user lockouts, and/or captchas for the forms you don’t want attacked at scale
- if you are storing credentials on your server (like password hashes), you better know what the options are for hashes, what a salt is, have investigated bcrypt and scrypt, know what happened when any of the thousands of large websites had their user databases leaked
- maybe support warning users that their credentials in your DB matches a record in HaveIBeenPwned and lock down their account until they password reset using their email address
- have a plan for when the hash you chose is deprecated in a few years while you aren’t paying attention and need to spent days re-coding to support new hash and legacy hash users, auto-migrating the legacies on next login
- want to support multiple 3rd party IDPs as well as local password auth? That starts to explode complexity and the number of forms.
- want to support SSO for enterprise? Use a framework that already supports SAML integration
There are roughly 3 phases in your career. In the first, you don't know much and do things simply, naively. In the second, you know quite a lot, and like it or not you will be quite attached to your own expertise, it will be part of your identity. Your solutions tend to be complex, but you believe they must be that way, and you have evidence this is so. In the third phase, you begin to perceive systems as ephemeral results of some causal chain, and have a sense of how they became the way that they are. This depth of understanding allows you to embrace simplicity again, but this time you understand precisely the limits of that complexity.
I think a lot of professionals (not just programmers) get stuck in phase 2. This is where, in our field, most of the code comes from: capable, smart people writing new code furiously, and with the not incosequential fact that it provably works. Sure, it has bugs, but you can get to those eventually. It also happens to be the most "defensible" phase, where you get to speak down to others - you have concrete experience, real knowledge, so you are justified. I would guess this is also the bulk of working programmers.
So, the OP's solution could be coming from a phase 1 or phase 3 place. You are certainly coming from phase 2. I would encourage you to stretch a bit and consider when the OP's simple solution makes sense, and when it doesn't. I would hope you would do this in an interview as well, because you'll find phase 3 people saying all kinds of whacky things, which might not make sense to you unless you ask.
(A careful phase 3 will make sure to preface his simple solution with his limits, and to not do so is a little bit sloppy, but personally I don't think that's a deal-breaker.)
Fair enough, but if you have reached phase 3, you would undoubtedly know that Auth logic is fairly complex and rolling your own half baked solution will put your users at risk?
I can't think of a situation where OP's solution makes sense. Except for the obvious cases (app will never be in production, will never have real users or contain valuable data, etc)
The OPs soln makes sense for an intranet application with a small-ish user base (e.g. an internal app used by startup personnel) In this case, the likelihood of threat models like brute-force attacks, XSS, etc are all dwarfed by other threat models (social, physical, etc). I think it's a good compromise; and at least they aren't storing passwords in the clear, and picked a good hash function! These are really low-hanging fruit and you'd be surprised how often even this goes wrong.
In any event, I also believe there is a generally better approach to auth that avoids a lot of the complexity of traditional approaches. It's speculative, but see my other comment in this thread: https://news.ycombinator.com/item?id=22157951