Security of login-data saved in browsers

Question

Most browsers provide an option to save login-data for later use.

Suppose a Windows workstation is located in a well-protected corporate LAN and only a well-defined set of application can be launched with a well restricted set of changeable in-app options.

In other words: No one is able to run arbitrary applications.

I wonder, how secure login-data is, which browsers save:

• Will this data get encrypted using the current Windows login security token?
• Will only the owner of the Windows account be able to access it?
• Are they - assuming practical compute-power - secure?

Regarding web-application:

• Should a web-app propose not to save login-data in browser.
• Can a web-app even reject login-data to be saved by browsers?

Practical means this: Not having enormous compute power or a Copacobana system.

Consequences:

• If not secure: Should no user ever store login data?
• If secure: Should user be instructed to save login data and afterwards eliminate the media by which the password was transferred to him.

Answer 1

The problem with web-browsers is that they run arbitrary code sent to them by random sites and ad-networks on the Internet. Because of this they are commonly the first line of defense for keeping the badware out. Some companies choose to manage this risk by greatly restricting where employees are allowed to go.

Over the years there have been a variety of attacks focused on extracting browser-cached login credentials. All browsers have some built in way to store login info, and a couple have plugins that extend or armor this very process (1password comes to mind). Browsers that use a single master process to do most things tended to be more vulnerable to these sorts of attacks.

Browsers are a lot better about this than they used to be, but it is still a risk that needs to be managed.

One thing to note though, is that with Internet Explorer it generally wasn't possible to get the user's Security Token the same way an attacker could get the cached site-passwords since the Windows security model requires a deeper penetration for that. Once the badware has installed a couple rootkits, all bets are off though.

Answer 2

"Secure" is a relative term. It depends on the threats you're trying to block. In general, the technologies which protect against one set of threats don't necessarily protect against other threats.

For instance, if you use CryptProtectData (which is best practice for saving per-user secrets) to save the secrets encrypted with the user's secret, you can't protect against an attacker who gets code running as the user. On the other hand, CryptProtectData will protect against an attacker who is running as another user (or who steals the hardware).

Similarly, using bitlocker can protect a hard drive from an external attacker (if you don't have the user's secret, the drive is unreadable). But if you have code running on the machine, bitlocker doesn't help at all.

If an attacker can get admin access to a machine, there are tools available it can decrypt the system logon information (worst case, the attacker can install a keylogger and sniff the users password.

Without knowing exactly the threats you're worried about, it's somewhat challenging to formulate a response to your question though. In general, a bitlockered machine joined to an AD directory where the user is a non administrator and is configured to use smart card logon+pin (2 factor authn) is reasonably secure against most threats, but not all.

Answer 3

You should be extremely careful about code that extends Internet Explorer's functionality. In Mac OS X for example, you'll find this login information stored under "Safari Forms Autofill" in Keychain Access, but attempting to copy that entry asks for your user password, meaning that native applications besides Safari cannot simply access it directly. I suspect a malicious Safari extension in ~/Library/Safari/Extensions could trick the user into revealing their passwords however.

You could also compromise passwords by employing a compromised SSL certificate in a DNS poisoning attack, which does not require running any code on the user's machine. You could reduce such risks by keeping your browser's CA list updated and jumpingo nthe DNSSEC bandwagon.