I’ve forgotten my MSN Hotmail password and I could easily reset it, as I DO
still have access to my alternate email account that I provided and I DO
remember the answer to my secret question.
However, it is imperative that I do not change/reset the password, but
instead recover the old one. It’s very complicated, but basically I have used
the same password for several things and I cannot afford to lose it.
What I am really asking is “Is it possible to merely recover my MSN password
rather than reset it??”
I normally don’t respond to password requests any more unless there’s
something new, like a change in Windows
Live Hotmail’s password recovery mechanism.
I’ve been getting the question above off and on for years. Even though many requests
are possibly legitimate, I can’t tell which ones are, and thus have to address them as password hacking attempts.
In other words, I have to ignore them.
But it dawns on me that there are some valuable lessons to be learned here.
Become a Patron of Ask Leo! and go ad-free!
Once again, I’ll cut to the chase and just tell you that no, there’s no way
to get your existing password back from MSN Hotmail or from any
security-minded service provider, free or not.
Care to know why?
They don’t know your password.
You probably think I’m nuts, but I’m absolutely 100% serious. A properly
secure authentication scheme, such as that we would hope is used by services
such as Hotmail, does not store your password. Instead, they store a
one-way encrypted or hashed form of your password. When you login they encrypt
whatever password you enter using the same algorithm, and if the encrypted
value matches the encrypted value they have stored for you, then you must have
entered the correct password.
Let’s say your password is:
Not an unreasonable password, hard to guess, short and probably easy-ish to
Using a hashing function (geeks: I’m using SHA1 in my example, but there are
many approaches), that password is transformed into:
Looks nothing like your password, right? However there are two incredibly
important characteristics of this transformation:
The chances of any other password generating exactly the same encrypted
string are infinitesimally small.
There’s no way to go backwards.
Re-read that second point. It means that in the example above there’s no way
given the “187483f86b7c516e35dc52aa30797f44e73ec734” to figure out that the
password you used to create it was “Pass!werd”.
The result? There’s no way for the service to tell you what you password is,
because they just don’t know. They’ll know the value that it encrypts into, but
that cannot be used to reverse-calculate what the password actually is.
You’re probably asking yourself why do services go through this messy
encryption stuff … why not just store the password directly? Wouldn’t that be
easier? It would certainly allow them to tell me what my password is rather
than forcing me to choose a new one.
In a word: security.
If someone hacks the service and somehow steals the user database, what do
they have? If they only have encrypted passwords, they have nothing of any use.
As a result, it’s considered “best practice” from a security perspective to
never store the actual password, but rather store an encrypted token derived
from the password instead.
So how do password resets work? It’s the one time that the system
briefly knows your password, because they:
pick a new password for you
save the encrypted password in their database
email the UNencrypted password to the email address of record
But even then, note how they did not save the unencrypted password.
They emailed it to you and then promptly “forgot” it, remembering only the