How does an attacker use Cryptographic nonces to generate access cookies through a script on a server? As what happened to Yahoo! servers.

  • 2
    It seems that your question is specific to how Yahoo was using nonce. You need to be more specific about what happened to Yahoo and what's your question.
    – Xavier59
    Sep 12, 2019 at 22:23
  • Yep, definitely change the title to include Yahoo! and the specific attack. Adding a reference in the body to the attack would also be very beneficial. Sep 12, 2019 at 23:26
  • @MaartenBodewes Thanks, changed the title. Sep 13, 2019 at 1:58
  • What makes you think cryptographic nonces are related to this data breach? Do you have a source for us? Sep 13, 2019 at 3:05
  • @AndrolGenhald csoonline.com/article/3180762/… Please read through this once. I was just trying to understand how the breach happened. Sep 13, 2019 at 3:42

1 Answer 1


I wonder if this was a not a mistake in the article. They call the stolen cryptographic values "nonces," but a nonce is intended to be used only once and I would not expect them to be stored in an account database because, depending on their use, the value would change many times during an authenticated session.

If I had to guess, what they call a nonce is actually a salted hash generated from their password and the script on the Yahoo server was allowing them to authenticate using the hash instead of checking the provided password against the stored hash.


After reading this, the "nonce" changes only after changing the password which to me indicates it is either their salted+hashed password or else some type of unique identifier for their account cryptographically generated based on their password and maybe other fields, but I suppose it could be based on other information entirely.

It is hard for me to guess what the script used to mint the cookies intended purpose was. It could be that it is part of their regular authentication process. It was available from the internet and so may have been called by the browser during authentication making it easier to find by the attackers. Maybe the browser called one authentication function to validate the username/pass and was returned the "nonce" which it used to call the function in question to generate the session token. Whatever it's intended purpose, in this case it allowed the attackers to bypass the traditional authentication process that salts+hashes the client provided input to compare to what is stored in the table, instead allowing the "nonce" value to generate a session token with the authorization granted to the account. The whole point in storing passwords in a salted+hash form is to prevent someone who successfully stole the account database from being able to use the credentials without a lot of extra work. With the referenced script on a server this step was basically eliminated and the results were not much different than if the passwords were stored in cleartext.

  • 1
    It sounds to me like the "nonce" is actually a per-user key used to MAC a predictable value, and the session cookie is value+MAC. Why they're calling it a nonce though is beyond me. Regardless, it's an unusual way of authenticating sessions. Sep 13, 2019 at 18:48
  • That makes sense. Sorry for all of the extra edits, I realized i was only focusing on the "nonce" and not the rest of the question.
    – Tony
    Sep 13, 2019 at 18:53
  • @Tony Thanks for the link you shared, gave some more info regarding the entire breach. I think the fact that they called it a 'nonce' is the most confusing part about this whole thing. Sep 14, 2019 at 23:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .