Hacker News Reader

Comment by methodover | Hacker News Reader

This is a good article. However, in regards to credential stuffing:

> Some guidance says to ban all passwords on this list. Try that and see how successful your users are at choosing passwords at all.

We're doing that. We don't let you choose any password that's been discovered in a prior breach.

Did Microsoft implement the same thing and discover a high rate of users bouncing off the registration page?

View on HN

Do you guys specifically alert the user that the password has been exposed publicly? If I got that sort of message, I would be grateful to the website rather than annoyed I couldn't use my favorite password.

We do yeah.

Here's the text: "This password has previously appeared in a data breach. Please choose a more secure alternative."

Not the password for you, just that password, for someone, on some site, ever.

If that’s happened thousands of times, sure, that’s the sign of a relatively common/weak password. If it’s happened once? I’d be frustrated if I was trying to pick something memorable and got stuck because of that.

Yes, I understand it was whether it's exposed anywhere, not just for this user. If it was someone else's password, I would still find it super valuable information to know I'm using something that's common enough to have been used by a stranger.

Just idly wondering... I wonder how many AJAX style sites do password checking server side and send the password to the server in plain text...

Hashing the password on the client doesn’t really gain you anything. The hash becomes the password (effectively), and you end up having to hash the hash on the server side to maintain security anyway.

https://security.stackexchange.com/questions/8596/https-secu...

I suppose it will be exchanged via HTTPS, so the risks are minimal...

What would the alternative be - sending the stored hash from the server so the comparison can be done on the client side? That doesn't sound like a great idea...

Reply on news.ycombinator.com