19 ms·
Are passwords stored in memory safe?
- consultutah 13y agoAre passwords stored in ____________ safe? No. Next question. ;) Are they "safe enough"? Maybe, it depends entirely on your use case.
- syntheticnature 13y agoInterestingly, one value that fits in that blank is "your head."
- btian 13y agoStill unsafe because I'll reveal it if they (e.g., NSA, CIA) torture me, threaten to kill my family etc.
- dsego 13y agoOr a new technology is invented to read the human mind.
- ogreyonder 13y agoOr 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-clips-from-brain-activity http://gizmodo.com/5843117/scientists-reconstruct-video-clip...
- aperrien 13y agoLike this technology? https://www.usenix.org/conference/usenixsecurity12/technical-sessions/presentation/martinovic https://www.usenix.org/conference/usenixsecurity12/technical...
- syntheticnature 13y agoThat's the idea -- even your mind is not a safe place for a password.
- deleted 13y ago[deleted]
- robmcm 13y agoAs this story illustrates: http://www.bbc.co.uk/news/uk-25745989 http://www.bbc.co.uk/news/uk-25745989
- joering2 13y ago+1. First, I wish to know what technology he used. Is TrueCrypt sufficient (with similarly strong password). Not because I have to hide anything, of course, just my wife wants me to encrypt our spicy photos, in case :) Second, I am not sure I understand the judge decision. If the man truly forgot it, or lets say the files on USB got corrupted (can happen) and the password he is giving out does not work, then how can you continue to jail him (for that reason)? Is this something specific to UK, or are similar US cases out there?
- aper 13y agoWhat if I have just erased my USB-stick with good dose of /dev/random and haven't actually formatted it to any filesystem yet. Good encryption is indistinguishable from randomness, so could they blame me for not giving up password and jail me for carrying randomness in my pocket?
- robmcm 13y agoI think they will use that to put you away, if they don't believe you...
- acdha 13y agoIn many countries they can jail you for failure to disclose encryption keys – for example, in the UK you could spend two years in jail unless you could convince the court that there was in fact no encrypted data on that USB key: http://en.wikipedia.org/wiki/Key_disclosure_law#United_Kingdom http://en.wikipedia.org/wiki/Key_disclosure_law#United_Kingd...
- 0xdeadbeefbabe 13y agoIf they did arrest you for that, but you aren't really Jack Bauer you could at least get points on hn for writing the story of "How I was arrested for carrying random data on my usb stick"
- Toenex 13y agothumb screws is all anyone would need with me.
- cobrausn 13y agoThe threat of lengthy prison sentences is the more 'civilized' version of this.
- saraid216 13y agoYeah. 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 13y agoSo 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 13y agoIn 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 13y agoYou 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 13y agoI would say no. http://en.wikipedia.org/wiki/DMA_attack http://en.wikipedia.org/wiki/DMA_attack
- ds9 13y agoSome 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 13y agoI 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 13y agoAre there any instances of this being used in the field?
- jamedjo 13y agoYes, 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-thunderbolt-dma-land-hacking-macs-through-the-thunderbolt-interface/ http://www.breaknenter.org/2012/02/adventures-with-daisy-in-... [2] http://www.researchgate.net/publication/49277520_Cold_Boot_Memory_Acquisition_An_Investigation_Into_Memory_Freezing_and_Data_Retention_Claims/file/79e415119b9e5376e1.pdf http://www.researchgate.net/publication/49277520_Cold_Boot_M...
- deleted 13y ago[deleted]
- billyhoffman 13y agoThe 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 13y agoFor 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 13y agoModern 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 13y agoHi. 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.pdf http://cansecwest.com/slides/2013/PrivateCore%20CSW%202013.p...
- 13y ago
- stygiansonic 13y agoWould 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
- andyjohnson0 13y agoWindows 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/aa380262(v=vs.85).aspx http://msdn.microsoft.com/en-us/library/windows/desktop/aa38...
- Fasebook 13y agoWe 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 13y agoI think this is worrying more about things like database passwords and API keys used by your application.
- treenyc 13y agoAnother 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.
- treenyc 13y agothank 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
- brownty 13y agoI'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 13y agothat would mean you would have access to the source code. Or do you mean the software is stored in the memory as well?
- brownty 13y agoI'm pretty sure it is (I might be wrong though)
- blt 13y agoIn 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.
- zobzu 13y agodon't forget mlock().
- bowyakka 13y agothis 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 13y agodon'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 13y agoNo, 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 13y 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 13y agoIt depends on your assumptions. How do you know you're running on Xen and not EvilXen?
- marcosdumay 13y agoVirtualization 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 13y agoYes, 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")