How does an attacker use Cryptographic nonces to generate access cookies through a script on a server? As what happened to Yahoo! servers.
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.