Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 17 submissions in the queue.
posted by cmn32480 on Thursday February 21 2019, @09:48AM   Printer-friendly
from the *********** dept.

A security consulting firm released a report on the safety of password managers. A non-geek, summarized version is also available at the Washington Post. (Summarized graphic of results.)

The password managers included in the study were 1Password 4, 1Password 7, Dashlane, KeePass, LastPass. Unfortunately, the testing was limited to Win10 even if the password managers were available on other platforms. They all had some flaws, but as reported, you should still use one. They were all tested for encryption method on the database, accessibility of the master password and keys in memory while unlocked, and the master password and keys in memory while locked.

All were evaluated to have adequate encryption on the file. 1Password 4 (which actually had better memory security than 1Password 7,) was best at keeping individual passwords safe in memory; while KeePass was best at keeping the Master Password safe in the memory tests (although Dashlane did the same while it while in a locked state.)


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 0) by Anonymous Coward on Thursday February 21 2019, @10:01AM (7 children)

    by Anonymous Coward on Thursday February 21 2019, @10:01AM (#804451)

    So, what methods could one use to safely store data (like passwords) in memory? I don't mean keeping it in memory while not being used, but how to safely load it into the memory to start using it in some unlocking function. Never saw this really covered in programming books/articles or documentation.

  • (Score: 2) by The Shire on Thursday February 21 2019, @11:25AM

    by The Shire (5824) on Thursday February 21 2019, @11:25AM (#804462)

    It really is a difficult problem. I suppose what I would do is generate a temporary key when the manager is unlocked which can be used by the app to retrieve a requested entry on demand. And if you lock the manager, you de-auth and destroy the key. Unlocking would then require reauthorization and the generation of a new temporary internal key. This way, even if the key in memory is retrieved it would no longer be valid by the time a bad guy tried to use it unless they had realtime access to your system, and in such a case you're already fully comprimised.

    Certainly at no time should you keep an entry in memory when the manager is locked.

  • (Score: 4, Insightful) by isostatic on Thursday February 21 2019, @12:55PM (1 child)

    by isostatic (365) on Thursday February 21 2019, @12:55PM (#804479) Journal

    Ltitle black book in your pocket. You're still screwed if you enter a password on a compromised machine, but at least it's only that password that's lost.

    • (Score: 2) by Teckla on Friday February 22 2019, @03:44PM

      by Teckla (3812) on Friday February 22 2019, @03:44PM (#805084)

      Ltitle black book in your pocket. You're still screwed if you enter a password on a compromised machine, but at least it's only that password that's lost.

      I have mixed feelings about this. The physical book itself could be lost or stolen. And could also be accidentally destroyed in a flood or fire.

  • (Score: 0) by Anonymous Coward on Thursday February 21 2019, @04:26PM

    by Anonymous Coward on Thursday February 21 2019, @04:26PM (#804555)

    With the Intel Management Engine (ME), you can hide data from your own user space, but if the ME is compromised, then it does not matter how secure your OS and software is. The only safe bet is to store your passwords away from the CPU and RAM. This is what Mooltipass and Memtype do.

  • (Score: 2) by meustrus on Thursday February 21 2019, @04:47PM

    by meustrus (4961) on Thursday February 21 2019, @04:47PM (#804570)

    It's not covered because storage of secure data ultimately must be managed by the OS. Without effective restrictions on which process can read what memory (including side-channel attacks), it's impossible to ever have security.

    Remember, your process doesn't have a secret sauce to decode that memory. Anybody with access to that memory the process binary can steal your keys and reverse engineer your algorithm and decode whatever you can decode.

    --
    If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
  • (Score: 4, Informative) by ElizabethGreene on Thursday February 21 2019, @04:50PM

    by ElizabethGreene (6748) Subscriber Badge on Thursday February 21 2019, @04:50PM (#804571) Journal

    It's hard to do right.

    For a password manager the user would enter a key to unlock the database, and you'd keep that key in one buffer only, not passing it by value. That buffer would be mlock() (Linux) or VirtualLock() (Windows) to keep it from paging. When a user asks for a password you only decrypt that one password, not the whole list and use similar precautions. When the password manager is locked or goes idle you explicity overwrite your buffers with zeroes or before freeing the memory.

    See also: Secure Programming Cookbook for C and C++ by Matt Messier, John Viega [amzn.to] (Amazon Link, but don't pay $80 for it. Get the $15 used copy or safari it.)

  • (Score: 2) by ilsa on Thursday February 21 2019, @09:48PM

    by ilsa (6082) Subscriber Badge on Thursday February 21 2019, @09:48PM (#804727)

    The thing is, if you have software sniffing the memory of other processes, then that means your computer is already compromised and you are already pretty screwed.

    While this is an issue, it's an issue that takes effort on the part of the malicious actor to exploit. All in all, using a password manager is still FAR FAR FAR better than not using one.