Ask HN: I just got a new password by email from info[at]ycombinator.com | Hacker News Reader

Ask HN: I just got a new password by email from info[at]ycombinator.com

16 pointsra16 comments

I didn't log in / out, or request a new password.

Has this happened to anyone else?

And is it possible to get the IP that requested this?

thanks

You have a very short username - could be that someone was looking at the "send a new password" page and made a mistake or was just plain curious.

I don't think I would worry about it too much unless I started getting lots of these emails.

A better way for Hacker News to handle password resets is to send the original email address associated with the account an email containing a one-time, expiring link allowing the user to change their password from. Otherwise, your password would remain unchanged.

Why is this better than current approach? Is it because the current password remain unchanged until the user click on the link to reset part?

Exactly. It allows people to easily reset their passwords if they've forgotten them while reducing their need to update their password if someone accidentally/maliciously attempts a reset.

I think a better method is to send a new password but continue to allow the users old password until they first login with their new password at which point the old is erased and only the new is valid.

It removes that extra step and is in turn simpler for the user. Rather than sending them this weird long URL - not such a problem with HN but with other less-technical sites I suspect this causes some confusion the first time someone experiences one.

This approach would introduce more complexity than it's worth, in addition to being less secure. Instead of just one password that can be used to login to your account, you now have two valid passwords.

I'm not convinced its less secure, the old password invalidates the second you login using your new password. This beats the current method which just locks you out (I believe anyhow? I've not tried it personally). Its along the same lines as the URL method but without the added confusion for the user.

Complexity for the developer perhaps, although you could also use the same branch of code to give you the ability to force password changes etc. And I think the added dev work is worth it for the user.

Time for some A/B testing perhaps.

At any moment, you can have two valid passwords used to access your account. Do all the A/B testing you want, this is NOT how you handle password resets.*

* Note that even my proposed solution is not the best way to handle password resets. Trust me on this, I've seen way too many applications do this wrong which have resulted in ability to compromise arbitrary users' accounts.

Please explain why, simply saying its not doesn't really add anything to the conversation nor convince me otherwise.

I'm not sure I understand why not. With your common URL method theres still two ways to authenticate, just as there is mine. They could "guess" the reset key just as easy as they could "guess" the new generated password. You'd have both expiring so the period for attack is minimal.

Please explain how my method is any less secure? Perhaps I'm missing some key security principles (likely), in which case please guide them to me. But just repeating that its less secure without backing up with some logic really doesn't convince me nor teach me anything.

Edit: I forgot to mention apologies - I'm not saying the password should remain as the one that was emailed. You can and should force people to change it upon the first login with their new password. Perhaps thats where the security confusion was. People storing passwords in email is poor, theres no debate there. Though yes, at a second thought this puts an extra step in for the user - A/B testing would be of use here.

Sorry for not explaining, maybe the following will convince you. When an application generates a password, about how long/secure are these passwords? (on average, and remember, we're staying user friendly...) Probably about 8-10 characters, alphanumeric, MAYBE a special character.

Now let's say you had to only create a link as I proposed. The length of the "secure" token can be as long as you want! Because the URL is not entered manually, you don't have to worry about being so "user-friendly" (as long as your url doesn't break in mail clients..)

If you fed a secure PRNG to an HMAC-SHA256/512 hash or a UUID... These values would be much, MUCH harder to guess than any password you could generate for your user. As a result, the following is not true:

> They could "guess" the reset key just as easy as they could "guess" the new generated password.

You bring up a good point about the password delivery over cleartext (though HN doesn't use SSL anyway, I didn't consider it at the time of posting). On a side note, does HN even have account lockout?

Yes, that is a much better way to do it.

Also the resetting user should be asked to provide their email address rather than the public forum username which is easily scrapped.

The admins probably have access to that info. I don't see how its going to help you though. If it was a malicious hack attempt then the person is probably running it through proxy or using dynamically allocated IPs making the IP addr worthless without a court order from a court in the country that has jurisdiction over the ISP/proxy.

Anyone can request new password for your account by entering your username.

Btw, just send you a new one.

Let's all do that O_o

it was me

oops

This is really tragic.

Reply on news.ycombinator.com