Comment by stouset | Hacker News Reader

Comment by stouset | Hacker News Reader

Parent Full thread

It's complicated, no?

Reasonable developers are qualified to do those things. But to build a full-featured authentication subsystem for their webapp? If it's something that holds any kind of reasonably private info, I'm not so sure.

Sure, a reasonable developer will use some sort of PBKDF to hash passwords. But when users need a password reset over email, will they know not to store unhashed reset tokens directly in the database? Will they know to invalidate existing sessions when the user's password is reset? Will they reset a browser-stored session ID at login, preventing fixation? And on and on and on. The answer to some of these questions will be yes, but most developers will have a few for which the answer is no. Hell, I've probably built more auth systems than most (and have reported/fixed a few vulnerabilities on well-known open-source auth systems to boot) and I'm honestly not sure I'd trust myself to do it 100% correctly for a system that really mattered.

Even outside of "holding the crypto wrong", these things have sharp edges and the more you offload to an existing, well-vetted library the more likely you are to succeed.

Based on breaches in systems like Okta and others, I don't think anyone knows how to do it 100% correctly.

Or the companies have figured out it's more expensive to hire a full time professional cryptographer to vet the process, than to deal with the PR for now more or less normalized data breaches.

Having worked at a competitor, I’ll simply say I know nothing specifically of Okta’s hiring practices, but it’s bold of you to assume they’re hiring any security engineers whatsoever. Still, this was twelve years ago when I was at the competitor in question so all the companies involved were was much smaller than they are today. But quite literally zero people at the particular competitor knew or even particularly cared about security.

There are different levels of security. The problem with confidently incorrect level is that it's worse than nothing. Having plaintext tokens (or even passwords) in a DB has its risks, but those risks are (a lot more) obvious, they are not shadowy bugs lying in wait under heaps of code.

Proving your point, but: What is fixation?

https://en.wikipedia.org/wiki/Session_fixation

In short, in at least one variation, the attacker is able to smuggle in a known (unauthenticated) session token into the victims browser. Once the victim logs in the session token is authenticated and known to the attacker.

The easy countermeasure is to renew the session token on login and not reuse a previously unauthenticated session token. Or your application has no session at all before login.

I am not a cryptography expert but even I know it's wrong that a company I worked at stored passwords in plaintext because my boss told me, customers call in to ask for their password and supports happily gives it to them.

When I rolled my eyes up, I soon got a termination.

Reply on news.ycombinator.com