On the Security of Password Managers

There’s new research on the security of password managers, specifically 1Password, Dashlane, KeePass, and Lastpass. This work specifically looks at password leakage on the host computer. That is, does the password manager accidentally leave plaintext copies of the password lying around memory?

All password managers we examined sufficiently secured user secrets while in a “not running” state. That is, if a password database were to be extracted from disk and if a strong master password was used, then brute forcing of a password manager would be computationally prohibitive.

Each password manager also attempted to scrub secrets from memory. But residual buffers remained that contained secrets, most likely due to memory leaks, lost memory references, or complex GUI frameworks which do not expose internal memory management mechanisms to sanitize secrets.

This was most evident in 1Password7 where secrets, including the master password and its associated secret key, were present in both a locked and unlocked state. This is in contrast to 1Password4, where at most, a single entry is exposed in a “running unlocked” state and the master password exists in memory in an obfuscated form, but is easily recoverable. If 1Password4 scrubbed the master password memory region upon successful unlocking, it would comply with all proposed security guarantees we outlined earlier.

This paper is not meant to criticize specific password manager implementations; however, it is to establish a reasonable minimum baseline which all password managers should comply with. It is evident that attempts are made to scrub and sensitive memory in all password managers. However, each password manager fails in implementing proper secrets sanitization for various reasons.

For example:

LastPass obfuscates the master password while users are typing in the entry, and when the password manager enters an unlocked state, database entries are only decrypted into memory when there is user interaction. However, ISE reported that these entries persist in memory after the software enters a locked state. It was also possible for the researchers to extract the master password and interacted-with password entries due to a memory leak.

KeePass scrubs the master password from memory and is not recoverable. However, errors in workflows permitted the researchers from extracting credential entries which have been interacted with. In the case of Windows APIs, sometimes, various memory buffers which contain decrypted entries may not be scrubbed correctly.

Whether this is a big deal or not depends on whether you consider your computer to be trusted.

Several people have emailed me to ask why my own Password Safe was not included in the evaluation, and whether it has the same vulnerabilities. My guess about the former is that Password Safe isn’t as popular as the others. (This is for two reasons: 1) I don’t publicize it very much, and 2) it doesn’t have an easy way to synchronize passwords across devices or otherwise store password data in the cloud.) As to the latter: we tried to code Password Safe not to leave plaintext passwords lying around in memory.

So, Independent Security Evaluators: take a look at Password Safe.

Also, remember the vulnerabilities found in many cloud-based password managers back in 2014?

News article. Slashdot thread.

Tags: encryption, Password Safe, passwords, security engineering

Posted on February 25, 2019 at 6:23 AM • 51 Comments

Comments

wiredog • February 25, 2019 6:32 AM

“LastPass obfuscates the master password while users are typing in the entry,”
And I really wish that LastPass, and everything that has you type in a password, would give you the option to not have it obfuscated like that. When I’m typing in that One Strong Password (with uppercase, lowercase, numbers, special characters, and did I just accidentally summon an Eldritch Horror?) it’s really easy to get typos. I’m not particularly worried about getting shoulder surfed when I’m by myself in my home office.

matteo • February 25, 2019 6:54 AM

i did a leak test some time ago against KeePass and found the same thing.
from what i remember when you unlock the db you can’t read in memory credentials, but as soon as you click “copy password” it will stay there forever, the more you click “copy password in clipboard” the more copies of the password you will find in KeePass memory.
to me seems that is clipboard win api or memcpy functions.

the author say on the website that even if he try to avoid this it is not 100% perfect.
windows is just not designed to protect ram, even if it offers api to do so.

from my humble analysis it looks a pretty solid password manager, i also tested it agains keylogger and if you use secure desktop (which should be called alternative desktop) keyloggers won’t work.
you have to code a specific keylogger to be able to keylog on the “secure” desktop

matteo • February 25, 2019 7:08 AM

few notes on KeePass:
-you should enable “secure desktop”, it’s not on by default because it’s incompatible with some programs, so try, if it works (mostly yes) keep it enabled, it helps a lot against keyloggers.
-you should set “Argon2” as key derivation function and click “set iterations so that they take one second”. this because argon 2 is the winner of slow hashing competition and by clicking one second it will mean that with your pc power it will take one second to test one password, this will make bruteforce almost impossible. default value is a bit low imho, but i understand that it’s a value that will work on any pc without slowing down too much the pc.

my two cents to the author:
-reevaulate secure desktop, i would find it nice to have it default on, maybe add a pre-test so that when you launch the program for the first time it say “i will test secure desktop”->a secure desktop window is shown with something like click ok if it works->no input for 10 seconds means secure desktop doesn’t work, fall back to nromal.
but expecting that people will enable it it’s not the best.

-set argon2 as default and set iterations so that they will take one second to compute on that pc by default too.

(please note that i tested the program last year, things might have changed since that time)
and thanks so much for the program!!

David - Qubes OS User • February 25, 2019 7:48 AM

I’m very curious how this relates to Qubes OS’ approach of isolating the password manager in a separate domain and then copying the password to the shared dom-0 clipboard. Anyone knows?

Marc Espie • February 25, 2019 7:50 AM

“But residual buffers remained that contained secrets, most likely due to memory leaks, lost memory references,”

Seriously, that’s a major defect of the programming language itself.

It is a well-known problem with C. Specifically, that memory accesses can be optimized away, and thus that even if you do clear a memory area, there’s exactly zero guarantee that it will actually happen.

or you can mark everything involved volatile, which is unreasonable, because it will be incredibly slow.
or you can switch to assembler, which doesn’t seem like such a good idea.
and even so, you don’t know if the compiler won’t decide to keep a copy of memory in registers, or the stack, or faster memory, and not clean it.

Why does this happen ?
– because it’s not part of observable behavior.
– because there is very little pressure on language designers to actually care about security.

I kid you not.

In OpenBSD, we added a specific API to clear memory, and Otto is working on a variation of malloc with further guarantees. But all those STILL rely on the compiler NOT deciding to optimize stuff away.

We already saw that issue, where a guarded malloc() was replaced silently by alloca-like allocation on the stack.

matteo • February 25, 2019 7:56 AM

@David – Qubes OS User

in Qubes everything is safe, no matter which password manager you use, you don’t even need to add a master password on the top of it.
the system full disk encryption is the master password and the qubes domain prevent other applications from stealing data.
not only! it prevent also clipboard stealing!

this means that only the domain in which you paste the password can steal your password, but usually the destination domain is exactly where the password should go, so if you have a “web bank” domain every app in that domain can steal your bank password when you paste it there from the “password manager domain” except that there are no apps in the “web bank” domain because that’s how qubes work, apps are in other domains “games vm”, “photo editing vm”, “office vm”, … 🙂 so yes, Qubes does it better

Alejandro • February 25, 2019 8:18 AM

I am a user and believer in PasswordSafe. Simply: It works.

It does NOT ‘phone home’ constantly sending massive encrypted data to who knows where for who knows what purpose. It’s NOT in the cloud, which as many know, is laughably insecure. It’s not asking me to upgrade for a fee or send ever more personal data to the developer for sinister purposes. It doesn’t want to work my camera, or microphone, or have access to my contacts.

Like I said, it just works and I am very happy with it.

Download from:

https://pwsafe.org/

Thanks again, Bruce!

Bill • February 25, 2019 8:27 AM

I’ve tested PasswordSafe in the same context of the other password managers. I did it by invoking a memory dump of the program while the app is open and unlocked. I’ve found that PasswordSafe keeps your master password in memory but it doesn’t reveal any of the account passwords until you copy them to the clipboard. I could not get the master password to reveal right away on a fresh vault but did show up after restarting the program and opening the vault.

kevin willoughby • February 25, 2019 10:04 AM

There is a variant of PasswordSafe that does allow sharing the safe among multiple (Apple) devices:
https://pwsafe.info

It requires a modest annual fee, but otherwise does everything I want it to. It had no problems reading my really old password database.

matteo • February 25, 2019 10:05 AM

@Vesselin Bontchev
yeah, i think too that these are more theoric attacks since if you can scrape ram you can also simply copy the whole db and plant a keylogger to get the master password.
but who knows… the app/windows might crash and windows send the dump on the net, also hibernation file/page file might hold some data.

@Alejandro
i’m using KeePass for the same reason, i don’t care about syncing i prefeer offline and no phone home.
i also avoid autofill plugins, they always end up introducing critical vulnerability, copy & paste, simple and secure.
auto fill might google the password instead of writing it in the right place…

Nice Robot • February 25, 2019 10:06 AM

I don’t understand why there isn’t more discussions of password generators like https://passwordmaker.org/

I use a private version of PasswordMaker and so that I don’t store passwords anywhere, ever! Problem solved! I have unique passwords generated on demand for every login I have. If someone sees me type my passphrase to generate my password, it does no good because I use custom generation rules too.

Dan W • February 25, 2019 10:19 AM

I filed a report about 1password 4’s secret leakage into memory several years ago. They replied promptly that they think they found a fix and would I please test a beta; unfortunately it was not fixed. They explained that due to the Delphi language they used, they could not do any better at controlling memory cleanup. As noted, v7 is far worse. So, I don’t let myself use it at work where process memory dumps can get submitted to our tools for debugging.

I did a similar test and bug report for Thycotic’s Secret Server and they did in fact fix the bug so an IIS dump no longer contains the secrets.

I’m glad this is getting some attention.

parabarbarian • February 25, 2019 10:22 AM

I do not use a password manager for important accounts. My banking account, PayPal, credit card, or email passwords are not stored in one. I use a password manager for those zillions of accounts I need to do trivial stuff like download a white paper or access a bulletin board. If any of those get compromised it would be an annoyance but not necessarily a tragedy.

That said, this does seem like an awful lot of work to do what a keylogger can do better. OTOH, it is a security hole that could be useful to criminals even if only in limited circumstances.

Mailman • February 25, 2019 10:28 AM

I will “speficially” as a password somewhere. It’s not a dictionary word, so it’s secure, right?

asdf • February 25, 2019 10:40 AM

If someone has compromised your device badly enough to read memory of arbitrary processes, I think a password file may be the least of your worries.

A stored secret can never be completely secure. Ever. There’s always going to be some way to steal it. Unless you’re being spear-phished, you don’t need to be perfect; you just need to be harder to crack than average, and the harder the better. This way the crackers will go after easier targets (plenty of schmoos out there.)

It’s like the old joke about two men being chased by a lion. One says, “The lion is too fast! We will never outrun him!” The other replies, “I don’t need to outrun the lion. I only need to outrun you.”

Who? • February 25, 2019 11:01 AM

@ asdf

If someone has compromised your device badly enough to read memory of arbitrary processes…

I would say it is not a big difference in the context of a world plagged of meltdown and spectre vulnerabilities, some of them yet to be discovered.

aoeu • February 25, 2019 11:21 AM

A little bit of process dumping for pwsafe later…

I can see my password in memory after I open up the entry for editing, but not right after I copied it to the clipboard. It’s also gone once I close the edit window. When it goes to sleep and locks itself, my password is gone from memory.

I don’t see my master password in memory at all after I’ve unlocked the safe file. The only time I do see it is while it’s sitting in the text entry field.

If I leave the edit window open for long enough that it falls asleep, the password for that entry stays in memory and it doesn’t lock the database. It looks like it crashed after I closed the edit window, too.

@Nice Robot: How do you deal with password policies that require you to change your password periodically? How do you deal with instances where the password database for a web site on which you have an account is known to be stolen? I don’t see any facilities for passwordmaker to change passwords.

Denton Scratch • February 25, 2019 11:40 AM

First: you don’t need physical access to read arbitrary addresses. You can own the machine remotely, and install a rootkit.

Second: I use PasswordSafe Portable edition, on a stick. It’s released through a different path from the desktop edition, so the build process may be different, I don’t know; and if the build is different, then the portable edition should be evaluated independently.

Third: I have been interested for some time in the minimalistic (huh? Why does the spellchecker dislike that word?) Linux command-line password manager called ‘Pass’ (bad name, makes it hard to google). If these memory leaks and such are the result of GUI libraries making it difficult to enforce correctness, then presumably doing without a GUI eliminates that weakness. I would like to see these same guys (or anyone else, actually) publish an evaluation of the security properties of Pass.

Of course, if you like the properties of Pass, but you want a GUI, you can do what the GPG4Win crowd did: let the GUI communicate with the core code through a command-line. I’m quite sure that that can be done wrongly, but it seems to me that it has to be much easier to manage memory cleanup than if you are linking your password manager code to some GUI library that wasn’t written with security in mind (are any of them?)

I am inclined to trust GPG; but I’m not sure I trust GPG4Win, despite the way they’ve separated the GUI from the core.

Leonardo Herrera • February 25, 2019 12:50 PM

I think the report is, above all, a publicity stunt. In order to take advantage of these “security issues” the attacking application need administrative rights, as the report itself says.

Rach El • February 25, 2019 2:22 PM

Thanks to the human who posted the link to the paper a few days ago, I intended to acknowledge them at the time. a basic yet salient overview, and happier still Mr Schneier has blogged about.

Clipboard was noted as a critical flaw. Goes without saying – we make that one kryptonite proof password and copy and paste it everyhwere

My response was a reminder of the utility and security of storing passwords on paper and I recall Mr Schneier suggests this. In lieu of a master password I would chose to obfuscate them.

Keepass is open source, tiny, operates entirely offline and by USB, and has helpful features.

I don’t believe in a password manager that has anything to do with the internet or that has the ability to share my information with anyone. Why this isn’t completely obvious to everyone is utterly disingenious, to me.

I can’t believe Lastpass even gets the honour of being spoken or written about – it deserves to be permanently exiled to the dust after their classic behaviour

Rombobjörn • February 25, 2019 4:06 PM

I see not one word about browsers’ built-in passcode managers.

As I understand it, the passcodes kept in these passcode managers are typically copied to website login forms. It seems relevant to study how the add-ons compare to the built-in one.

Ulrich Boche • February 25, 2019 4:38 PM

There is an iOS app named “pwSafe” that works with PasswordSafe databases. You can sync with Dropbox, iCloud or via USB cable.

For Android, there is an app named “PasswdSafe” that works with PasswordSafe databases. If you don’t want to sync your database manually, there is another, additional app named “PasswdSafw Sync” that can sync the database with Dropbox, Google Drive, OneDrive, or ownCloud.

dragonfrog • February 25, 2019 6:12 PM

I use Passwordsafe Sync on my Android phone, so my password database isn’t lost forever if I should drop my phone in the dish water. It works quite reliably and is simple to set up.

I haven’t set up syncing on my computer though. I’m sure there’s a way, I just don’t need it badly enough to really research it.

1&1~=Umm • February 25, 2019 9:11 PM

One comment that catches the eye from the article,

“However, each password manager fails in implementing proper secrets sanitization for various reasons.”

That is ALL the password managers tesyed failed to keep ‘secrets’ secret…

There are various ways you could look at this,

1, The luck of the draw, that all they chose to test failed.

2, The majority of, if not nearly all, password managers do fail to the tests.

3, The password managers were specifically selected for the report because they had failed.

4, There is a reason of ‘imposed policy’ that all the popular password managers fail.

The first unlikely as coincidence often appears, is probably the most likely reason. Though the second is almost as likely, because modern OS’s and many programing languages just don’t alow sufficient control over buffers and memory especially those in kernel space to make reliable removal of secrets easy to implement.

Whilst the third is possible, it is unlikely because what would the authors realy gain by doing so.

And yes the fourth does sound just like a conspiracy theory in the making. But unfortunately we do know that undue influence has been applied to some companies to make what are backdoors for officialdom. And it would appear from what has been reported in the past that more than a few believe that AV companies have bowed down to official requests and removed tests for ‘official attack code’ from their products. Likewise before the Ed Snowden collected NSA documents started to be revealed few would have considered it an option. However since the document releases more and more people would think such ‘Official influence’ was not just possible but probable.

Like most others I don’t know, but erring on the side of caution would seem to be the wise thing to do. Especially as some of these password manager apps give the impression of being rather more complex than strictly needed.

Johnny W • February 25, 2019 9:25 PM

@asdf

If someone has compromised your device badly enough to read memory of arbitrary processes, I think a password file may be the least of your worries.

There’s a reason we don’t keep the passwords in a text file named “passwords.txt” on the user’s desktop. Security is not absolute. Every bump in the attacker’s road decreases the chance ithe attack would continue.

David Kowis • February 25, 2019 10:44 PM

There’s also the newest player, the Open Source Bitwarden. I’d like to know how that one measures up, because the source code is actually available. So if you want to run your own, not on any cloud, you can. Or you can just use their cloud version. I would expect that this would lead to much greater security of that provider.

1&1~=Umm • February 25, 2019 11:13 PM

@Nice Robot:

“I don’t understand why there isn’t more discussions of password generators like ‘passwordmaker'”

A look at the website via the link you provides suggests that all they have done is implemented a simple password system not that disimilar to those in use since Bob Morris (Snr) put together the *nix password system using a modified version of DES.

I’ve not looked at the code as the explanation in ‘How it works’ gives me sufficient cause for concern, to not proceed with it.

In essence their explanation is,

‘password’=hash(‘secret’+’URL’)

Where ‘secret’ is the ‘master password’ which I’m guessing from ‘that one, single password you like’ does not change for each password generated. Which leaves the strength of the system on the ‘URL’ which to be frank if it is of the standard form,

http://www.xxx.yyy.zzz

Has very little entropy as ‘www’ is a constant and ‘zzz’ is often one of only three or for such as ‘com’ or ‘org’.

Which leaves ‘xxx’ and ‘yyy’ which originally would have been seven ASCII lower case alphas or less. Which even today with considerably less restrictions is still low entropy.

The other problem is dictionary type attacks. All of the ‘www.xxx.yyy.zzz’ appears somewhere in the DNS system of which the likes of Google hold a fairly complete record in what is effectively a database so fascilitating dictionary style attacks.

But it’s actually worse than that because of estimates that say the over 90% of users, use one or more of only a handfull of URLs. On the assumption you need only ten URLs modifing a current cracking programe such as ‘John the Ripper’ (JtR) could breeze through and build ‘Rainbow tables’ to use as a lookup, when one service password becomes known, the master password can just be looked up.

The chances are with many if not most users ‘that one, single password you like’ for the master password, is going to be as short, thus as easy to type, as they can get away with.

Matt • February 25, 2019 11:47 PM

I remember that I didn’t choose password safe because when I looked at it, it was Windows only and therefore a non-starter for me. The sync problem can be mostly solved with dropbox. I use Keepass for my most important secrets (and only unlock it on my linux desktop at home), and Lastpass for my medium/low importance secrets which I unlock much more liberally.

David • February 26, 2019 12:03 AM

There is an Ubuntu deb package for Password Safe, fully interworking with a Windows generated safe file

Weather • February 26, 2019 12:34 AM

I’ll try to add something to zeroing memory,
If you call memset on windows, with size of buffer the buffer gets copyed to 3 plus locations, one for cmpstr ,one for strlen, one for old buffer, one for new buffer.
Cmpstr,strlen don’t have a zero function, new buffer realise on future, the only one removed is old buffer with C call to memset or C++ to zeromemory
To do it make it stack unsigned char mpass, and inline code
Mpass[I] = 0x00
I++
Or better code
Asm moved eax, ss:0x05 (holds pointer is 0x0250000)
After a call to memzero with mpass as parm
Asm moved ebx, esp-0x04
Asm moved ECX, 0x00
Top:
Asm mov edx, [ebx]
Asm mov [eax], edx
Asm add ECX, 0x01
Asm add ebx, 0x01
Asm add eax, 0x01
Asm cmp ECX, 32 (max hardcoded size of buffer
Asm jnz top
Asm ret
Asm cmp ECX, 32
Asm jz cont
Asm jmp error

we're all individuals • February 26, 2019 1:18 AM

If I were an attacker that could read arbitrary memory on a target’s machine, I would certainly be able to install a modified version of the target’s password manager that would give me access to the password data with much less muss & fuss…

As @Leonardo Herrera wrote, the report is basically a PR stunt, to draw attention to the author’s firm.

P.S. – FWIW, PasswordSafe does a decent job of protecting the data in RAM.

TheInvisibleMan • February 26, 2019 1:52 AM

Password Manager is an essential tool to protect your online privacy. A good password manager will be tremendously helpful to secure your online accounts and it also educates you on the best practices related to online security. I am a very big fan of the Security Challenge from LastPass for instance.

GCG • February 26, 2019 3:36 AM

How about the Trezor password manager ?
is this something usable in your opinion

https://wiki.trezor.io/User_manual:Password_Manager

thank you for this great article

Gerard van Vooren • February 26, 2019 3:41 AM

@ Marc Espie,

Why does this happen ?
– because it’s not part of observable behavior.
– because there is very little pressure on language designers to actually care about security.

I kid you not.

C has lots of problems, one of them is the standards committee, which is unable / unwilling to create necessary changes. For decades that is.

Howcome there is no “secure” version of C? Let’s say C 2.0? I can think of lots of changes, including the use of modules which would solve a lot of problems on their own. Of course there should also be a sort of “go fmt” and “go fix” that could fix your source code where ever possible.

There is also C2, that isn’t standardized.

Adrian Simmons • February 26, 2019 8:04 AM

Interesting. Somewhat disappointed they didn’t include Enpass, which I switched to, from 1Password, because of decent cross platform sync (mac/linux/iOS/windows) long before anyone else seemed to have it.
It uses third party services for sync, like dropbox, but otherwise defaults to local storage (no cloud). But I hadn’t considered this sort of leakage. They’re at https://www.enpass.io/

Petre Peter • February 26, 2019 9:19 AM

The moment i write something on paper, i consider it compromised. Richelieu has taught me that.

Larry • February 26, 2019 11:25 AM

@wiredog
I like Lastpass, but I agree with you. I emailed L.P. asking them to consider the option & the reply was they would consider it(not holding my breath!). I use a long, but memorable master P.W.
Still, it’s easy to make a typo! For other sites, I use an unmask password extension on my Chromebook, but I’m not real comfortable with it as I’m not sure how secure it is.

Keith • February 26, 2019 5:19 PM

Whenever the topic of password managers comes up I mention PasswordSafe, or pwsafe, or passwdsafe. I’ve used most all of the variants as I moved through phones. I currently use the iOS and Mac versions and keep the database on iCloud to keep them synced. Thanks Bruce!

Jesse Thompson • February 26, 2019 5:51 PM

Well, I use the following hybrid approach to make the most out of my password manager.

choose a decent entropy password suffix that you memorize. 5-8 ascii characters, for example.
Use a password manager to create random password for each site, and store those passwords.
Don’t use those exact passwords, but instead always manually suffix your easy to type, only-ever-memorized suffix.

Example: you choose universal, good entropy, suffix via diceware or whatever. Let’s say “p/xFB”.

You never store this in the password manager, nor any other digital place save when authorizing yourself whereupon you have confidence the data will be discarded after use instead of stored.

You sign up for an account at schneier.com, have password manager create a quick, randomized password for you for this site. Let’s say it chooses “R^<KxDD\EXEV”. You store this password in the manager for this site, but you do not actually use that password for your account.

Instead, you fill in this password in the create new password (and confirm password) fields, and then you manually type your suffix that you have memorized on the end of both. So you would get:

R^<KxDD\EXEVp/xFB

Password Manager may offer to save this password for you once it notices it in use, just decline to do so to keep any variant of your suffix out of storage.

Now every time your manager auto-fills a password form, you just focus the password field, press end and then manually type your suffix before finally logging in.

Now you are safe from the following attack vectors:

Somebody somehow getting an unencrypted copy of your password safe does not have enough to impersonate you on any of the sites listed without your suffix.
Somebody somehow learning your suffix does not have enough to impersonate you on any site either without the contents of your password manager.
The suffix adds security to innumerable credentials while only requiring you to memorize one more credential object.

Sure some sites require you to have say “6-8 character passwords, can only use the letter T” or whatever. But there’s not a lot I can do to help out those clowns. :/

Gerard van Vooren • February 27, 2019 1:57 AM

@ Jesse Thompson,

“Well, I use the following hybrid approach to make the most out of my password manager.”

There are other ways, such as using a small “password+website_name” and then SHA256, but that is still an approach that just doesn’t work.

What would work? Well, I thought that using OpenID would work, but that only works when you have enough momentum, which AFAIK it doesn’t.

One month ago I visited a presentation where they talked about IRMA (I Reveal My Attributes). IRMA is a Dutch Open Source platform hat is being developed by the Radboud University Nijmegen, The Netherlands and the Privacybydesign foundation. The IRMA app is available for Android (Google) and for iOS (Apple).

In the website there is LOTS more info, including schematics and the github source code (written in Java, Go, C, C++ and JS) and it has a BSD license.

Here is a youtube link.

Gerard van Vooren • February 27, 2019 2:12 AM

@ Jesse Thompson,

And this is the way to open a fridge to get a beer with IRMA 😉

Jesse Thompson • February 27, 2019 3:12 PM

@Gerard van Vooren

There are other ways, such as using a small “password+website_name” and then SHA256, but that is still an approach that just doesn’t work.

Well, the reason the approach you mention here would not work for me is that it cannot be done without additional software.

I may have neglected to mention this benefit in my list, but my approach can be practiced at the drop of a hat with no other software than

whichever off the shelf password manager you desire to use +
whatever method you wish to use to securely generate the suffix password.

Does Diceware even count as “software” though? lol

And this is the way to open a fridge to get a beer with IRMA 😉

If I didn’t know any better I would presume that the person just purchased a brew via Bitcoin or something. Also, QR code approach reminds me a lot of SQRL.

Erik-J • February 27, 2019 9:09 PM

@matteo
“I did a leak test some time ago against KeePass and found the same thing.
from what i remember when you unlock the db you can’t read in memory credentials, but as soon as you click “copy password” it will stay there forever, the more you click “copy password in clipboard” the more copies of the password you will find in KeePass memory.”

@Bill
“I’ve found that PasswordSafe keeps your master password in memory but it doesn’t reveal any of the account passwords until you copy them to the clipboard.”

@Rach El
“Clipboard was noted as a critical flaw. Goes without saying – we make that one kryptonite proof password and copy and paste it everywhere”

I always try to avoid the clipboard, I select the password by a double-click and pull it to the password field, same for the account name.

This select-and-pull seldom fails and is more convenient than the copy-paste that needs the keyboard. My only fear is to accidentally drop the password somewhere in between.

Mind I’m not very computer savvy, and I wonder if this is any safer than the common copy-paste using the clipboard?

(I use this select-and-pull for those stupid repeat your email address forms too.)

Weather • February 27, 2019 10:54 PM

Erik
About the clipboard it might or might not, if the password manager reads mouse clicks and location it could set the text cursor and press virtual keys, it would stay within the manager,it would switch between windows frames, asynckey etc.

TRX • March 1, 2019 12:25 PM

While it’s quite reasonable to wonder about buffers and stale memory used by a password manager, you also have to consider that every keystroke still has to go through multiple desktop and OS layers. And who even knows what’s running in the web browser any more? And hope that server you’re talking to is using https, or your password is in plaintext all the way there.

If you have malware running with enough access to inspect memory in running programs, your password manager isn’t the first problem you need to deal with.

Mare • March 6, 2019 12:42 PM

I wonder why we still need to use passwords however.
The easiest and actually much safer way to authenticate is one without any password (or passwordmanager).

Sabine (Server) sends a random challenge to Ulla (User) who wants to authenticate. Ulla signs that challenge with her private key. Sabine checks with the public key Ulla has registered beforehand, that this Challenge has indeed been signed by Ulla. And voila Ulla can go in and use the service. And if you use a hardware token, you don’t actually have to keep a private key on disk.

Thats called “Webauthn” and Of course we need Sabine implementing this first, but it is easy and saves a lot of hassle for Ulla.

Once “Webauthn” (already finalized by the W3c) gets starting, we won’t need any Passwormanagers anymore. Hopefully.

Since all of the Challenge/Response Pairs are One-time only, keeping them in Memory after login is a not so big problem.

1&1~=Umm • March 6, 2019 5:13 PM

@Mare:

‘Once “Webauthn” (already finalized by the W3c) gets starting, we won’t need any Passwormanagers anymore. Hopefully.’

Your hopes will be dashed.

Webauthn takes a lot of CPU cycles, which might not be noticeable on 64bit 2GHz desktops and similar devices, but will be a definite performance killer on many lower end devices.

The other thing is whilst ‘password’ storage might by 30bytes on a traditional system from the late 1960’s onwards, the size of public keys is getting way big these days, thus 1-2Kbyte/account is getting on for seventy times the size per account.

This key size issue ‘might’ need to get many times that size rather quickly if the right sort of Quantum Computer becomes a reality for cracking current public key systems.

There are other ways of achieving a similar result to Webauthn using symetric keys without incuring either the vast size or cracking risk of public key…

But I can easily see pasword managers in one form or another, still being in thirty to fifty years from now.

Mare • March 7, 2019 12:47 PM

@1&1~=Umm

‘Webauthn takes a lot of CPU cycles, which might not be noticeable on 64bit 2GHz desktops and similar devices, but will be a definite performance killer on many lower end devices.’

Actually my hardware token does most of the calculation. And tHat token is quite slow compared to a modern mobile phone, but it suffices for a login (and encrypting/decrypting text). The browser is just the middleman in this scenario.

‘This key size issue ‘might’ need to get many times that size rather quickly if the right sort of Quantum Computer becomes a reality for cracking current public key systems.’

Sure, by the time Quantum computing gets feasable, we need other mechanisms altogether. But that time has not come yet. Actually all current SSL in your webbrowser will not be safe anymore by that time, so storing your password might not be your biggest concern. Transporting the password safely to the website is of a much bigger concern. But what happens then, is really all theories up to now.

Ty • March 10, 2019 12:20 AM

My lastpass password was changed today without my consent and without any notification in my inbox. I was not able to login. They do allow you to reset your password even if you have forgot it, which means they have a copy of your master password somewhere and can do whatever they want with it if they are compromised.

Other strange activity. I recently had some kind of lastpass software installed on my windows machine that I was previously not aware of. It had a dll always loaded “\%temp%\temp\BullseyeCoverage-2-x86.dll” that was flagged only by eset sysinspector as dangerous, not by any malware scans.

“BullseyeCoverage is a C++ code coverage analyzer used to improve the quality of software in vital systems such as enterprise applications, industrial control, medical, automotive, communications, aerospace and defense.”

I don’t recall installing Lastpass anywhere but in browser. I tried installing lastpass for windows later hoping to BullseyeCoverage-2-x86.dll, but I could not locate it. NSA?

This is the only other source I could find on bullseyecoverage and lastpass: https://forums.lastpass.com/viewtopic.php?t=290175, a search for this dll brings up many malware sources.

Ty • March 10, 2019 12:32 AM

(continued) I had changed my password last week for the first time in a year after I found this software on my computer, suspecting my password may have been compromised. Now my password is changed without my consent and without any notification in my inbox from lastpass. Last time I changed my password I received a notification in my inbox. This suggests they may be colluding with governments and should be shut down. Only use password managers operating outside the jurisdiction of the 14 eyes.

Ty • March 10, 2019 12:47 AM

Lastpass “Account Recovery detected. It is essential that you immediately change your password! Enter a new password and password hint. You will not be prompted for your old password.” Thus they have a copy, so its all on them. My password was changed without my consent, they should be put out of business.

Schneier on Security

On the Security of Password Managers

Comments

Leave a comment Cancel reply