Are passwords stored in memory safe?

[InclinedPlane]

If you can't trust the OS you're screwed regardless. If you are concerned about physical access based attacks (like cold boot) then there are alternatives.

Here's some interesting reading: http://en.wikipedia.org/wiki/TRESOR

[zurn]

If the OS is actively plotting against you, it's a losing game, but if it's just security-oblivious then there may be some things you can do mitigate. Consider for example, an OS with a habit of writing out random parts of your process memory onto disk.

[belorn]

For security beyond just trusting root (and by proxy, mostly the OS itself), there are options but the amount of work needed increase quite steeply. I am pretty sure that SELinux could provide some defense against memory reading by root, however it takes a lot of configuration and setup to get it done "right".

If one want to leave the OS altogether, One could also use a external physical security device, through it too need to be done in a correct way. Some hardware encryption acceleration devices might have an option to store keys only locally and never give it away to the host, but I doubt this is true for all.

[pbsd]

FWIW, TRESOR is bypassable: http://seclab.ccs.neu.edu/publications/acsac2012dma.pdf

[btilly]

Not entirely true!

See http://en.wikipedia.org/wiki/Homomorphic_encryption for more.

[DanBC]

There are attacks on passwords stored in RAM. There's an example against the Apple keychain. Root can run the software and it collects a bunch of passwords for logged in users (http://juusosalonen.com/post/30923743427/breaking-into-the-o...)

But there are best practices for passwords, and those reduce the risks; and most attacks need privileges and access to the machine, which again reduces the risk.

If you're worried about stormtroopers kicking the door down and squirting liquid nitrogen on the RAM you probably have enough money to have very strong perimeter defences.

[kmfrk]

An air duster suffices for this purpose. No need for something so fancy as liquid nitrogen.

[StavrosK]

What does liquid nitrogen on the RAM do? I was under the impression they plugged the computer into a UPS or something and took it.

[Murk]

At the company I worked for previously we frequently used a firewire DMA attack such as inception (http://www.breaknenter.org/projects/inception/) to gain access to computers, and dump ram to recover other passwords.

[mappu]

I'm familiar with DMA attacks, but it's always shocking to see publicly available GPL code that just works against popular and recent versions of windows, OS X and linux. UEFI Secure Boot is no help if you signed a 1394 driver : )

Everyone should read the mitigation steps and caveats as appropriate.

If you have physical access to an unlocked windows machine, i'd reach for mimikatz. Instant plaintext.

[amadvance]

There are well known attacks that allow to read memory, and even write, thought DMA.

See for example:

0wned by an iPod - hacking by Firewire http://md.hudora.de/presentations/#firewire-pacsec

More papers are linked in the wikipedia page: http://en.wikipedia.org/wiki/DMA_attack

[FourthProtocol]

Reading comments here and on stackexchange I'm surprised that no mention is made of the Data Protection API (DPAPI) on Windows, which is designed specifically for this purpose.

http://msdn.microsoft.com/en-us/library/ms995355.aspx

I've been using it for years, and while nothing is infallible, any sensitive plain text in my apps isn't there for more than it takes to encrypt and then destroy.

I can't comment on Linux or OSX but would be surprised if the OS didn't offer a similar API tied to the principal to protect in-memory data.

[laumars]

    > Reading comments here and on stackexchange I'm surprised
    > that no mention is made of the Data Protection API (DPAPI)
    > on Windows, which is designed specifically for this purpose.

It was mentioned and quickly dismissed as not being effective:

1) if it can be decrypted by the API, then it can be cracked by any process given enough time and resources.

2) further to point #1, the Data Protection API was reversed engineered in 2010.

3) security is only as strong as your weakest link, and that API doesn't address the "weakest link" of running malware locally. eg it's much easier to keylog passwords to begin with than to scan the RAM.

I'm inclined to agree with those comments. While that API is a nice idea, I think it's a little ineffective in practice.

[qompiler]

For this reason the Java JPasswordField getPassword() method returns an array with no other copies around. An array can also easily be zero'd out with fill().

http://docs.oracle.com/javase/tutorial/uiswing/components/pa...

[viraptor]

Isn't JRE using compacting GC which makes the "no copies" guarantee void anyway?

[thomas-st]

Is it possible that a (non-privileged) process could read data of a process that has previously terminated by looking at uninitialized memory and gain access to sensitive information that way?

[FooBarWidget]

Most operating systems clear the ram pages when the process exits, or when it requests a page, so no.

[FooBarWidget]

One method that I've thought about in the past is hashing your password using bcrypt, then zero and free the original password, and check all future authentication attempts against the bcrypt hash. Nobody, not even you, knows the password now, just whether a given password is correct.

[Mahh]

Hashing passwords for storage is standard practice in all systems that involve password based authentication.

Even then, the password must reside in memory at some point in order to compute the hash of your password [using bycrypt or whatever scheme], which is necessary for both generating the hash the first time AND generating the hash for authentication attempts. This is the issue described in the given link.

http://en.wikipedia.org/wiki/Cryptographic_hash_function#Pas...

[mappu]

Of course. But just using hashes doesn't mean you're safe - watch out for pass-the-hash and replay attacks, as well as session hijacking and other possible side channels.

[ars]

The question is about storing the password for you to authenticate to somewhere else, not the reverse.

Storing a hash doesn't help because the remote site won't accept it. And if it did then the hash is essentially the password and you've violated the goal.

[eaxbin]

Random Access Memory Memory?

[RKearney]

It's where ATM Machines store their application code while running.

[surferbayarea]

Here's what I do. The login page on my browser is sent to my phone which creates a https session with the remote website and then hands over the session back to the browser. The mechanics to do this are a bit tricky but like a few days of coding. The advantage: your password never ever enters your computer's RAM(or HDD/network)...take that keyloggers!

[alanctgardner2]

What about phone malware? And what stops someone reusing the https session as you move it from your phone to your desktop?

[icebraining]

Smart cards can move the private key from the PC to a dedicated, self-contained and (supposedly) safer machine - the card itself.

[DanBC]

I'm worried that the smart cards and their software is well designed, but then you have to rely on other vendors to do thier bit securely.

Fravia said of dongles that they were often great, with nice libraries, but when software vendors implemented them they would use stupid methods.

(http://home.scarlet.be/detten/tuts/dongle_zeezee.htm)

> Don't panic when you read all info about dongle security. They ARE secure. OK. You can't crack them unless they're done by complete idiots. OK. But you want to crack the application, NOT the dongle. When you read about RSA encryption, one-way functions and see in the API some interesting Question/Answer hashing functions, remember that it's only API. No one uses it. Only simple functions like Check/Serial Number/Read and sometimes Write are used.

[yxhuvud]

Safety is a float - not a boolean.

A more appropriate question would have been: 'How safe is it to store passwords in memory?'

[_cbdev]

A quick CTRL+F didn't find anything, so I might actually be the first to point out that "RAM memory" is a case of the RAS Syndrome :)

http://en.wikipedia.org/wiki/RAS_syndrome

[jayfuerstenberg]

All you can do if you don't trust the OS is to assemble the password at the point of use (each time) and erase the memory location directly afterwards.

And even that is not 100% foolproof (the OS can detect it in between these two steps).

[Tichy]

Also, is there a way to erase specific memory locations, and a guarantee that in the meantime that memory location has not been cached somewhere else?

[mariusmg]

Or keep it encrypted in memory

[niggler]

This is why ssh-agent is awesome: they don't hold the passwords in memory (only the keys) so you minimize the number of times you type password and the number of places it is stored.

[ygra]

But the key is what you authenticate with after all, so why go after the password when reading memory when you can go after the key directly?

[wslh]

No, I found a password in the pagination file of an old Windows.

[diminish]

hey security experts, are microprocessor registers or cache, subject to any security attacks?

[dfox]

It depends on whether you consider attaching JTAG ICD and just reading whole state of CPU out an security attack. In some aspects just attaching an ICD to desktop CPU is simpler than attacks on physical security that involve freezing DRAM chips and reading their contents with patched BIOS or whatever. On the other hand it mostly requires attacker to have JTAG ICD that supports that particular CPU. Almost all x86 chips have some kind of ICD interface, usually very low-level and complete one. But because of low level nature of registers you see through it, JTAG register maps and so on are NDA-only and thus ICDs that support non-embedded CPUs tend to be very rare and in the realm of "you can't afford it if you have to ask the price". But they exist and buying one is more about the price than about any questions of the kind "why do you need that?". But because of rarity of these things most current research simply ignores this attack vector.

Bottom line: there is no such thing like security against local attacks on almost any kind of commodity hardware (including TPMs, excluding devices explicitly designed to be reasonably secure like gaming consoles). When you need that you also need proper tamper-proof hardware.

[mje__]

Power analysis can also be used if you can force the CPU to do work on the key/password. It's been used to extract key material from smartcards

edit: finish the sentence

[zokier]

Maybe some timing attacks would be the closest thing to CPU cache based attack.