Recovering Internet Explorer Passwords: Theory and Practice
1. Introduction
2. Types of passwords stored in Internet Explorer
2.1. Internet Credentials
2.2. AutoComplete data
2.3. AutoComplete passwords
2.4. FTP passwords
2.5. Synchronization passwords
2.6. Identities passwords
2.7. AutoForms data
2.8. Content Advisor password
3. Brief overview of Internet Explorer password recovery programs
4. PIEPR – the first acquaintance
5. Three real-life examples
5.1. Recovering current user’s FTP passwords
5.2. Recovering website passwords from unloadable operating system
5.3. Recovering uncommonly stored passwords
6. Conclusion
1. Introduction
Nobody will likely dispute the fact that Internet Explorer is today’s most popular Web browser. According to the statistics, approximately 70% of online users prefer to use just this program. Arguments about its pros and cons may last forever; still, this browser is the leader of its industry, and this is a fact that requires no proof. Internet Explorer carries several built-in technologies, designed to make average user’s life easier. One of them – IntelliSense – is made for taking care of the routine tasks, like the automatic completion of visited webpage addresses, automatic filling of form fields, users’ passwords, etc.
Many of today’s websites require registration, which means, user would have to enter user name and password. If you use more than a dozen of such websites, you will likely need a password manager. All modern browsers have a built-in password manager in their arsenal, and Internet Explorer is not an odd. Indeed, why would one have to remember yet another password if it is going to be forgotten some time soon anyway? Much easier would be to have browser do the routine work of remembering and storing passwords for you. It’s convenient and comfortable.
This would be a totally perfect solution; however, if your Windows operating system crashed or reinstalled not the way it’s supposed to be reinstalled, you can easily lose the entire list of your precious passwords. That’s the toll for the comfort and convenience. It’s good just about every website has a saving ‘I forgot password’ button. However, this button will not always take your headache from you.
Each software developer solves the forgotten password recovery problem their own way. Some of them officially recommend copying a couple of important files to another folder, while other send all registered users a special utility that allows managing the migration of private data, and the third ones pretend they are not seeing the problem. Nevertheless, the demand creates the offer, and password recovery programs are currently on a great demand.
In this article, let’s try to classify types of private data stored in Internet Explorer, look at programs for the recovery of the data, and study real-life examples of recovering lost Internet passwords.
2. Types of passwords stored in Internet Explorer
- Internet Explorer may store the following types of passwords:
- Internet Credentials
- AutoComplete Data
- AutoComplete Passwords
- FTP Passwords
- Synchronization Passwords for cached websites
- Identities Passwords
- AutoForms Data
- Content Advisor Password
Let’s take a closer look at each listed item.
2.1. Internet Credentials for websites
Internet credentials mean user’s logins and passwords required for accessing certain websites, which are processed by the wininet.dll library. For example, when you try to enter the protected area of a website, you may see the following user name and password prompt (fig.1 http://www.passcape.com/images/ie01.png).
If the option ‘Remember my password’ is selected in that prompt, the user credentials will be saved to your local computer. The older versions of Windows 9a stored that data in user’s PWL file; Windows 2000 and newer store it in the Protected Storage.
2.2. AutoComplete Data
AutoComplete data (passwords will be covered further) are also stored in the Protected Storage and appear as lists of HTML form field names and the corresponding user data. For example, if an HTML page contains an e-mail address entry dialog: once user has entered his e-mail address, the Protected Storage will have the HTML field name, the address value, and the time the record was last accessed.
The HTML page title and website address are not stored. Is that good or bad? It’s difficult to determine; more likely to be good than bad. Here are the obvious pros: it saves free space and speeds up browser’s performance. If you think the last note is insignificant, try to imagine how you would have to perform several extra checkups in a multi-thousand (this is not as rare as it may seem to be) auto-fill list.
Another obvious plus is that data for identical by name (and often by subject) HTML form fields will be stored in the same place, and the common data will be used for the automatic filling of such pages. We will see this by this example. If one HTML page contains an auto-fill field with the name ‘email’, and user entered his e-mail address in that field, IE will put in the storage, roughly, ‘email=my@email.com’. From now on, if the user opens another website, which has a page with the same field name ‘email’, the user will be suggested to auto-fill it with the value that he entered on the first page (my@email.com). Thus, the browser somewhat discovers AI capabilities within itself.
The major drawback of this data storage method comes out of its advantage that we just described. Imagine, user has entered auto-fill data on a webpage. If someone knows the HTML form field name, that person can create his own simplest HTML page with the same field name and open it from a local disk. To uncover the data entered in this field, such person will not even have to connect to the Internet and open the original WWW address.
2.3. AutoComplete Passwords
In the case with passwords data, however, as you might have guessed, the data will not be filled in automatically. Since auto-complete passwords are stored along with the Web page name, and each password is bound to only one specific HTML page.
In the new version, Internet Explorer 7, both AutoComplete passwords and data are encrypted completely different; the new encryption method is free from the shortcoming just described (if that can be classified as a shortcoming.)
It is worth noticing that Internet Explorer allows users to manage auto-fill parameters manually, through the options menu (fig.2 http://www.passcape.com/images/ie02.png).
2.4. FTP passwords
FTP site passwords are stored pretty much the same way. It would be relevant to notice that beginning with Windows XP FTP passwords are additionally encrypted with DPAPI. This encryption method uses logon password. Naturally, this makes it much more difficult to recover such lost passwords manually, since now one would need to have the user’s Master Key, SID and the account password.
Starting with Microsoft Windows 2000, the operating system began to provide a Data Protection Application-Programming Interface (DPAPI) API. This is simply a pair of function calls that provide OS-level data protection services to user and system processes. By OS-level, we mean a service that is provided by the operating system itself and does not require any additional libraries. By data protection, we mean a service that provides confidentiality of data through encryption. Since the data protection is part of the OS, every application can now secure data without needing any specific cryptographic code other than the necessary function calls to DPAPI. These calls are two simple functions with various options to modify DPAPI behavior. Overall, DPAPI is a very easy-to-use service that will benefit developers that must provide protection for sensitive application data, such as passwords and private keys.
DPAPI is a password-based data protection service: it requires a password to provide protection. The drawback, of course, is that all protection provided by DPAPI rests on the password provided. This is offset by DPAPI using proven cryptographic routines, specifically the strong Triple-DES and AES algorithms, and strong keys, which we’ll cover in more detail later. Since DPAPI is focused on providing protection for users and requires a password to provide this protection, it logically uses the user’s logon password for protection.
DPAPI is not responsible for storing the confidential information it protects. It is only responsible for encrypting and decrypting data for programs that call it, such as Windows Credential manager, the Private Key storage mechanism, or any third-party programs.
Please refer to Microsoft Web site for more information.
2.5. Synchronization Passwords for cached websites
Synchronization passwords free user from having to enter passwords for cached websites (sites set to be available offline.) Passwords of this type are also stored in IE’s Protected Storage.
2.6. Identities passwords
So are identities passwords. The identity-based access management mechanism is not widespread in Microsoft’s products, except, perhaps, Outlook Express.
2.7. AutoForms Data
A special paragraph must cover the form auto-fill method, which constitutes a hybrid way of storing data. This method stores the actual data in the Protected Storage, and the URL, which the data belong to, is stored in user’s registry. The URL written in the registry is stored not as plaintext – it is stored as hash. Here is the algorithm for reading form auto-fill data in IE 4 – 6:
===8RemoveAll();
//Check if autoform passwords are present in registry
if ( EntryPresent(cszUrl) )
{
//Read PStore autoform passwords
return PStoreReadAutoformPasswords(cszUrl,saPasswords);
}
return FALSE;
}
//Check if autoform passwords are present
BOOL CAutoformDecrypter::EntryPresent(LPCTSTR cszUrl)
{
assert(cszUrl);
DWORD dwRet, dwValue, dwSize=sizeof(dwValue);
LPCTSTR cszHash=GetHash(cszUrl);
//problems computing the hash
if ( !cszHash )
return FALSE;
//Check the registry
dwRet=SHGetValue(HKCU,_T(“Software\\Microsoft\\Internet Explorer\\IntelliForms\\SPW”),cszHash,NULL,&dwValue,&dwSize);
delete((LPTSTR)cszHash);
if ( dwRet==ERROR_SUCCESS )
return TRUE;
m_dwLastError=E_NOTFOUND;
return FALSE;
}
//retrieve hash by given URL text and translate it into hex format
LPCTSTR CAutoformDecrypter::GetHash(LPCTSTR cszUrl)
{
assert(cszUrl);
BYTE buf[0x10];
LPTSTR pRet=NULL;
int i;
if ( HashData(cszUrl,buf,sizeof(buf)) )
{
//Allocate some space
pRet=new TCHAR [sizeof(buf) * sizeof(TCHAR) + sizeof(TCHAR)];
if ( pRet)
{
for ( i=0; i0 )
pHash[dw]=(BYTE)dw;
//actual hashing stuff
while ( dwDataSize–>0 )
{
for ( dw=dwHashSize; dw–>0; )
{
//m_pPermTable = permutation table
pHash[dw]=m_pPermTable[pHash[dw]^pData[dwDataSize]];
}
}
}
===8
About the Author
Ivan Orlov, Ñhief programmer. http://www.passcape.com