I think the process was that a user was sent a 'forgot password' link. When they clicked the link, they were redirected to `wmPassupdate.html` with the cookie `referer={base64(email)}` set. Then, when users submit the password update form, the `referer` cookie is used to authenticate them, but it can be trivially generated.

tptacek will be shortly along to explain how password reset links are typical and one of the most common mistakes.

How you should just "take the hit" (the cost is trivial) and store a randomly generated nounce in your database rather then do shenanigans like encoding user information in the url with secrets and bad cryptography and what not.

See? We listen! :)

Do you have any examples of someone further explaining what you are suggesting? Or if you have time, can you further elaborate on this point? I glanced at the nounce article on wikipedia and if I understand correctly you are suggesting:

1) user creates account (which generates nounce)

2) when password resetting via email auth via nounce.

3) when password is reset regen nounce

Is that right? Just trying to better understand what appears to be a good approach to password resets.

Here's a recent post of somebody else channeling tptacek: http://news.ycombinator.com/item?id=4940291

I got it from a quick 'password reset' search here, I recall a lot of these discussions, if you're curios click around on a few more results. :)

That's basically right. Generally you generate the nonce when someone clicks the 'forgot password' link, but I suppose you could do it when someone creates the account as well.

I'm confused. How exactly is the nonce to be used if without a link?

I was under the impression that best practice was a link with a randomly generated key that has an expiration date (and is expired as soon as it is used). The only security hole here is if the email is intercepted (and you've got other problems at that point).

This system didn't use a nonce or a key referenced against a database. It simply base-64 encoded the email address.

i think you're actually agreeing. what one of you is calling a key the other calls a no[u]nce.

the implicit (worse) alternative is that you encrypt or sign additional state in the url (and in this case, base64 was the "encryption").

I realize that key == nonce in my post. My point was against the statement "emailing password reset links is bad and not best practice." You need an password link to make use of the key/nonce. The point of the nonce isn't to eliminate links. It's to make the attack surface that much smaller by limiting their power.

It sounds like the link in the "Password reset" email doesn't use a secret one-time expiring token, but instead base64-encodes the user's email address, so it can trivially be generated by an attacker.

Not just that, but there was a self-help page for self-registering your own account (the first screenshot):

> It seems that Facebook was trying to avoid the creation of accounts in Accellion after removing the register form from the pageview

> I discovered that if you know the direct ___location of the form (/courier/web/1000@/wmReg.html), You can easily bypass that protection and create an account in files.fb.com,

Once he created his own accounts, he could test out his exploit code on his created accounts.