
Are passwords stored in memory safe?  - amalantony06
http://security.stackexchange.com/questions/29019/are-passwords-stored-in-memory-safe
======
billyhoffman
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/](https://citp.princeton.edu/research/memory/)

update: link to images/videos:
[https://citp.princeton.edu/research/memory/media/](https://citp.princeton.edu/research/memory/media/)

~~~
aryastark
For Linux there is TRESOR ([http://www1.informatik.uni-
erlangen.de/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.

~~~
RexRollman
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)?

~~~
sweis
Hi. L3 caches are indeed huge these days. For example, the latest Mac Pros are
shipping with 30MB L3 caches.

You can do a lot with that space. My company PrivateCore runs an entire
Linux/KVM stack within the L3 cache, then fully encrypts main memory. Someone
physically acquiring memory would only obtain plaintext.

Note that a software compromise could still read memory. That's one reason why
it's necessary to fully attest a system before provisioning it with any keys
or passwords.

Here's a CanSecWest talk with more details:
[http://cansecwest.com/slides/2013/PrivateCore%20CSW%202013.p...](http://cansecwest.com/slides/2013/PrivateCore%20CSW%202013.pdf)

~~~
informatimago
You mean cypher text. Plain text is clear text is unencrypted.

------
andyjohnson0
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...](http://msdn.microsoft.com/en-
us/library/windows/desktop/aa380262\(v=vs.85\).aspx)

~~~
Fasebook
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
I think this is worrying more about things like database passwords and API
keys used by your application.

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

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

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

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

~~~
dsego
Or a new technology is invented to read the human mind.

~~~
ogreyonder
Or a technology already exists :)

"UC Berkeley scientists have developed a system to capture visual activity in
human brains and reconstruct it as digital video clips..."

[http://gizmodo.com/5843117/scientists-reconstruct-video-
clip...](http://gizmodo.com/5843117/scientists-reconstruct-video-clips-from-
brain-activity)

------
coldcode
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?

~~~
AnimalMuppet
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
I would say no.

[http://en.wikipedia.org/wiki/DMA_attack](http://en.wikipedia.org/wiki/DMA_attack)

~~~
ds9
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
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...

------
stygiansonic
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](http://en.wikipedia.org/wiki/TRESOR)

------
zvrba
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.)

------
ricardobeat
> 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?

~~~
marcosdumay
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).

~~~
ricardobeat
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")

------
zobzu
don't forget mlock().

~~~
bowyakka
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)

~~~
zobzu
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 :)

------
treenyc
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.

~~~
brownty
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.

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

~~~
blt
In a compiled language, it would be part of the binary. If you opened up
"checkpassword.exe" in a hex editor, you'd see the password clear as day
somewhere in the static data section.

In an interpreted language, the interpreter would create some kind of string
object containing the contents of the password in memory, and getPassword()
would return that object when called.

~~~
treenyc
good to know. I guess the best thing is to NOT store password at all in the
the code? Rather in encrypted databases?

~~~
mpyne
You should never store a password. If absolutely needed you could store a
derivation of that password from a KDF like scrypt, and then see if the user's
password _derives_ to that same value. This is how checking for login
passwords is done on Unix and Unix-like systems with shadow passwords (which
never store the user's password).

And even with all that I probably screwed something up, but that advice is
still better than storing plain passwords.

~~~
lkjsdflkj
Nobody ever thinks of the case where a program has to _supply_ a password and
not just check it. For example, suppose your program (that runs unattended)
has to interact with some JSON-RPC API, and the remote server expects a
password. That password has to come from _somewhere_.

~~~
mpyne
You should use public-key crypto for this case when possible. _Any_ key you
bake into the binary _will_ be a publically-known password for anyone who gets
access to that binary. With public-key crypto it's safe to include the public
key and then make an ad hoc session key using secure key exchange.

