Deep Analysis of Internet Explorer Password Storage Mechanism: From API to Encryption Implementation

Overview of Internet Explorer Password Storage Architecture

As an integral component of the Windows operating system, Internet Explorer's password management mechanism has undergone significant technological evolution. From versions 4.0 to 6.0, IE employed a unified "Protected Storage" system within the registry to manage all types of passwords. However, starting with version 7.0, Microsoft implemented a more granular password storage strategy, utilizing different storage locations and encryption methods based on password type.

Analysis of Password Types and Storage Locations

IE version 7.0 and above categorizes passwords into two main types, each with distinct storage mechanisms:

HTTP Authentication Password Storage

Passwords for HTTP Basic and Digest authentication are stored in encrypted files within the user's profile directory. The specific path is %APPDATA%\Microsoft\Credentials. This directory contains not only IE's HTTP authentication passwords but also LAN computer login credentials and other system-level passwords. This centralized storage approach aligns with the architecture of Windows Credential Manager.

From a technical implementation perspective, these password files are encrypted using the CryptProtectData API. This function generates encryption keys based on the current user's login credentials, ensuring that only the same user account can decrypt the data. The encryption process can be represented as:

DATA_BLOB DataIn, DataOut;
// Initialize DataIn with password data
CryptProtectData(&DataIn, L"IE HTTP Auth Password", NULL, NULL, NULL, 0, &DataOut);
// DataOut contains encrypted data ready for file writing

The corresponding decryption operation uses the CryptUnprotectData function:

DATA_BLOB DataIn, DataOut;
// DataIn reads encrypted data from file
CryptUnprotectData(&DataIn, NULL, NULL, NULL, NULL, 0, &DataOut);
// DataOut contains decrypted original password data

Form Auto-complete Password Storage

Username and password fields in web forms (typically marked with <input type="password">) employ a different storage strategy. These passwords are saved in a specific Windows Registry location: HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\IntelliForms\Storage2.

The core characteristic of this storage mechanism is URL-bound encryption. The encryption key incorporates not only user credentials but also website URL information, increasing the complexity of password recovery. Technically, IE passes the URL as an optional entropy parameter when calling CryptProtectData, enhancing encryption strength:

DATA_BLOB DataIn, DataOut, EntropyBlob;
// Set EntropyBlob with URL information
CryptProtectData(&DataIn, L"IE Form Password", &EntropyBlob, NULL, NULL, 0, &DataOut);

This design means password recovery requires two simultaneous conditions: consistent user context and knowledge of the original URL. If a user clears browsing history or has never visited a particular website, the corresponding password cannot be decrypted.

Comparison with Windows Standard Credential API

Although IE password storage also utilizes the CryptProtectData/CryptUnprotectData encryption function pair, its overall architecture differs significantly from the Windows standard credential management API (CredRead/CredWrite).

CredRead/CredWrite provides a unified credential management interface that encapsulates both encryption and storage within a single API. When calling CredWrite, the system automatically encrypts data using CryptProtectData and stores the result in a protected system area. Users can centrally view and manage these credentials through the Control Panel's "Credential Manager" interface.

In contrast, IE implements custom storage logic:

• Decentralized Storage Locations: HTTP authentication passwords in the file system, form passwords in the registry
• Metadata Management: IE must independently manage additional information like URL binding and timestamps
• Recovery Limitations: URL-bound encryption for form passwords increases recovery difficulty

Security Considerations and Technical Limitations

IE's password storage design reflects a multi-layered security strategy:

1. User Context Isolation: Encryption based on user login credentials ensures other users cannot access password data
2. Process Boundary Protection: CryptProtectData defaults to the CRYPTPROTECT_LOCAL_MACHINE flag, restricting decryption operations within the same user context
3. Administrator Privilege Requirement: Accessing the %APPDATA%\Microsoft\Credentials directory typically requires elevated permissions

However, this design also introduces practical limitations. Password recovery tools (such as NirSoft's IE PassView) must be able to access original URL information when recovering form passwords. If browsing history is cleared, tools require users to manually provide URL lists or revisit corresponding websites.

Developer Practice Recommendations

For developers needing to implement password storage in applications, it is recommended to prioritize Windows standard credential APIs over imitating IE's specific implementation:

// Using CredWrite to store credentials
CREDENTIAL cred = {0};
cred.Type = CRED_TYPE_GENERIC;
cred.TargetName = L"MyApp:Server1";
cred.CredentialBlobSize = passwordSize;
cred.CredentialBlob = (LPBYTE)password;
cred.Persist = CRED_PERSIST_LOCAL_MACHINE;
CredWrite(&cred, 0);

// Using CredRead to retrieve credentials
PCREDENTIAL pCred;
CredRead(L"MyApp:Server1", CRED_TYPE_GENERIC, 0, &pCred);
// pCred->CredentialBlob contains decrypted password

Advantages of this approach include:

• Standardized Management: Users can manage all application credentials through a unified system interface
• Security Inheritance: Automatic inheritance of Windows security models and updates
• Compatibility Assurance: API behavior remains stable across different Windows versions
• Backup Support: Credentials can be backed up and migrated along with user profiles

Conclusion

Internet Explorer's password storage mechanism demonstrates Microsoft's evolutionary thinking in browser security design. By dispersing passwords by type and incorporating URL-bound encryption, IE seeks balance between convenience and security. However, from system integration and maintainability perspectives, Windows standard credential APIs offer developers more standardized and sustainable solutions. Understanding these underlying mechanisms not only aids security assessment and troubleshooting but also provides important references for designing new authentication systems.