Are passwords stored in memory safe?

http://security.stackexchange.com/questions/29019/are-passwords-stored-in-memory-safe

by amalantony06 • 13 years ago

129 72 13 years ago

security.stackexchange.com

consultutah• 13 years ago

Are passwords stored in ____________ safe? No. Next question. ;)

Are they "safe enough"? Maybe, it depends entirely on your use case.

syntheticnature2• 13 years ago

Interestingly, one value that fits in that blank is "your head."

btian• 13 years ago

Still unsafe because I'll reveal it if they (e.g., NSA, CIA) torture me, threaten to kill my family etc.

robmcm3• 13 years ago

As this story illustrates: http://www.bbc.co.uk/news/uk-25745989

Toenex• 13 years ago

thumb screws is all anyone would need with me.

saraid216• 13 years ago

Yeah. Safety and security seem to be fundamentally misunderstood by most people: they simply don't know what a threat analysis is, how to do one, or why it's important. If you can't answer, "From who?", then the answer is flatly, "No."

I have a hard time understanding why such a skill is so rare. It seems sort of useful.

coldcode• 13 years ago

So given the stories about the Target hack, which mentions "memory scrapers", how can this be done on an entire network of (Windows in this case, no idea what version) systems? I assume you would have to have discovered an escalation attack that gave you sufficient privileges to read another processes' memory. But even given that, how do you find what bytes are useful to scrape?

heywire• 13 years ago

In past cases, some of these ram scrapers have been in the form of dlls which are injected, by Windows (AppInit_DLLs), into the intended process.

AnimalMuppet• 13 years ago

You do it with entropy calculations. Crypographic material (encrypted data and/or keys) has higher entropy than unencrypted data (even if the data is binary). You scan the memory looking for high-entropy regions.

Note that this doesn't work if the entire memory is encrypted, but I can't imagine how a computer could function with the whole RAM encrypted.

pixelcloud• 13 years ago

I would say no.

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

ds9• 13 years ago

Some servers used to have a resettable "case has been opened" flag in the BIOS - the pieces that was based on could be leveraged against the DMA attacks. Overwrite certain items in memory, or maybe just power off the system, when the box is opened, and obstruct opening of the box (a lot of glue? or somesuch) to extend the time past the "recover memory" window.

Yes, I realize this would still be susceptible to coercion of the humans involved, and other issues, but it could be a building block of some degree of NSA-proofing.

dm2• 13 years ago

I see this option in my bios switched every time I open my computer. I never thought it might be a security feature, just an flag that must be set for someone with mild OCD.

I'm still not sure how my motherboard detects if my case is open...

frankHQ• 13 years ago

Are there any instances of this being used in the field?

jamedjo• 13 years ago

Yes, very easy. In a mac you just plug in a Firewire/thunderbolt device[1]. More extreme measures involve freezing the RAM. Both require physical access to the machine, but a bit more scary that plugging your laptop into a public display/TV gives an attacker control of your computer and passwords.

Full disk encryption TrueCrypt/BitLocker/FileVault can act as countermeasures[2] and modern versions of OSX don't allow DMA from the login screen anymore.

[1] http://www.breaknenter.org/2012/02/adventures-with-daisy-in-...

[2] http://www.researchgate.net/publication/49277520_Cold_Boot_M...

billyhoffman2• 13 years ago

The raw memory itself isn't safe either.

Ed Felton did some great work (2008) where he physically removed the sticks of DRAM from one computer, stuck them in another, and read their contents. But doesn't DRAM lose it's content without continuous power? Not if you turn a can of compressed air upside down and spray the chips first, cooling them to -50C! He used this to recover encryption keys and defeat whole disk encryption.

Pretty crazy stuff: https://citp.princeton.edu/research/memory/

update: link to images/videos: https://citp.princeton.edu/research/memory/media/

aryastark3• 13 years ago

For Linux there is TRESOR (http://www1.informatik.uni-erlangen.de/tresor). It uses CPU registers, which can prevent this sort of attack. However, you're limited to one encrypted drive with this method.

RexRollman2• 13 years ago

Modern CPUs have a lot of cache these days. Couldn't the keys be store there are well (assuming the threat is just the removal and reading of RAM)?

sweis3• 13 years ago

TRESOR only helps against passive attacks since since the code is still exposed in memory. Active attacks that modify memory can easily circumvent it.

r00fus• 13 years ago

So does this mean that the non-upgradeable computers with soldered RAM (i.e., MacBook Air) are more secure?

ketralnis• 13 years ago

It means that they're resistant to that attack, sure (which is distinct from being "more secure" as if there were some continuum). The Air is also resistant to the firewire DMA attack, in that it doesn't have firewire

dobbsbob• 13 years ago

Doesn't work on DDR3 ram. Cold boot attacks are extinct. There's also stuff like this you can combine with encrypted swap http://www.onarlioglu.com/privexec/

stygiansonic• 13 years ago

Would something like TRESOR[1] along with RAM encryption help? Or would this just move the attack target to the CPU itself? (Certainly this would be harder to attack than sticks of DRAM, like was demonstrated by a group a few years ago)

I guess the number one thing is to prevent physical access, and failing that, make an attack that targets RAM take longer.

1. http://en.wikipedia.org/wiki/TRESOR

andyjohnson0• 13 years ago

Windows has a CryptProtectMemory() function [1] that can be used to encrypt in-memory secrets using an OS-allocated session key. As far as I know the key is stored in non-paged memory in kernel memory space.

On Linux, libgcrypt can do encrypted malloc, which might also help.

[1] http://msdn.microsoft.com/en-us/library/windows/desktop/aa38...

Fasebook• 13 years ago

We store passwords' one-way hash + salt only, we don't even know what our users' password are, they are never in memory to begin with. Even if someone got access to the stored value in memory somehow, they wouldn't know what to input to get that result for some time.

kiernan• 13 years ago

I think this is worrying more about things like database passwords and API keys used by your application.

treenyc5• 13 years ago

Another recommendation that I learned from an old boss is the following.

1. Store password in a function and return the password. 2. Whenever the password is needed call the function.

Example in JS.

function getPassword(){ return 'I am a password'; }

if(req.data.password == getPassword()){ passwordIsCorrect(); }else{ passwordIsNotCorrect(); }

This is not for sure. Core dump and debug dump usually dumps variables, but not the source code of program.

brownty2• 13 years ago

I'm pretty sure that this wouldn't be safe. By simply disassembling the software you would see the strings stored in the application itself, so you could easily find any password stored that way.

treenyc5• 13 years ago

that would mean you would have access to the source code. Or do you mean the software is stored in the memory as well?

Strilanc• 13 years ago

This is bad advice. The password ends up in the program's binary where it is easily accessible. Also, users can't change it after it's compromised.

treenyc5• 13 years ago

thank you everyone for correcting my ignorance.

that more diverse the people are the more perspective we can look at a problem:

collective indulgence >= individual common sense

Thanks HN

zobzu2• 13 years ago

don't forget mlock().

bowyakka• 13 years ago

this wont secure the memory just prevent it from being paged to disk, if I had access to your user or to root I can just read it directly via say proc (or any of the other attack vectors)

zobzu2• 13 years ago

don't forget mlock() regardless. they're talking about how the OS will page to disk in TFA. My comment answer that with mlock - for platform that have it of course :)

zvrba• 13 years ago

No, and neither are cryptographic keys derived from passwords, and neither are cipher tables derived from cryptographic keys.

A simple defense would be to access all such material through a permutation table. (Which need not be explicitly stored in memory, but could be computed by means of multiplication modulo a prime.)

ricardobeat2• 13 years ago

virtual machines and cloud computing cannot be ultimately safe

Can somebody with more expertise comment on this? I was under the impression that virtualization software (Xen etc) was deemed safe?

wmf• 13 years ago

It depends on your assumptions. How do you know you're running on Xen and not EvilXen?

marcosdumay• 13 years ago

Virtualization software protects the host against software running in the virtual machine. It's completely useless for protecting the virtual machine from the host (as you'd want on the cloud).

ricardobeat2• 13 years ago

Yes, but how is hacking the host infrastructure different from hacking your own infrastructure (in case of a dedicated server)? You'll always have external trusted third-parties unless you also maintain your own datacenter and network provider. I can't see how cloud is inherently less secure unless the host acts against their own interests.

(all this in context of the statement that "if you are serious about security, use dedicated hardware")

Are passwords stored in memory safe?

Related Stories