brownell's comments

> I'm still on two generation back

Perhaps that's why you aren't asked?

"Of the USA"? Is the USA a continent now?

Perhaps not saving cookies is something bots tend to do, hence the number of attempts...

So 1 million possible passwords? That's straight-up terrible entropy these days.

Excuse my ignorance... You're saying that if someone blocks you on Twitter you're no longer allowed to post something with their @handle? Or that they, as the blocker, just won't see it?

If it's the former, then I would agree with you. If it's the latter, and you're not actually blocked from posting (saying) anything, then where exactly is the violation?

The random-salt has to be stored, at least for the length of the authentication request, because the server needs to generate the same hashed-hashed-password as the client to be able to match and authenticate.

> Alternatively a timestamp would be just as good.

I don't see how that would work at all.

I also don't see the need to go any further in detail about how this scheme will not be better than the current best practices.

Never. Roll. Your. Own. Crypto. https://security.stackexchange.com/questions/18197/why-shoul...

So let me make sure we're on the same page...

--

Server stores hashed-password, hash-salt, and random-salt.

Server sends hash-salt, and random-salt to client.

Client uses user password and hash-salt to generate hashed-password.

Client hashes hashed-password using random-salt.

Client sends hashed-hashed-password to server.

Server grabs stored hashed-password and hashes used stored random-salt to check for match against client's hashed-hashed-password.

--

So the only thing this actually does is not share the text of the password that the user typed to the server. But at a technical level, now the hashed-password is the new "password".

Let's say the database is compromised. The attacker has the hashed-password. They make a login request to fetch the random-salt, hash their stolen hashed-password with it and send that to the server. Owned.

Along with being more complicated with no real gain, this also takes the hashing away from the server-side, which is a big negative, as the time that it takes to hash a password is a control method used to mitigate attacks.

Just send the plain-text password over HTTPS and hash it the moment it hits the server. There's no issue with this technique (as long as it's not logged!)

Did you even read the comment you replied to?

Years ago they did not delete accounts. They would deactivate it and never delete the data. They do now (apparently), but in the past they were very openly not deleting anything.

I think you're missing something...

parseInt('08', 10); // 8