Hacker News Reader

I felt the same way until I read the conclusion, "we want to point out that the security team at LastPass responded very quickly to all our reports and lot of the issues were fixed in just a couple days. It was very easy to communicate and work with them."

That is why I use LastPass. Because they aren't perfect, but they realize that their reputation for taking any vulnerability very seriously is the most important asset they have.

I have heard great things about KeePass so if you make that switch good on you.

Edit: Added "very seriously" above.

Does it matter if the support is OK if the app doesn't fulfill its primary purpose which is to keep your data safe?

Yes, because every system has flaws in it. Nothing is perfect and given enough time and resources an exploit will be found. Knowing that, if the team listens and fixes the issue, the product goes forward being more secure and trustworthy.

Safe is a relative term and not at all binary.

LastPass does exactly the thing I use it for, does it well, and does it mostly transparently. Allow me to easily use different passwords per site. While my LastPass might be hacked one day, if I reuse passwords, then my accounts will be hacked eventually. Not a question of if, but when.

Whenever news comes around that a particular site got hacked, I don't even pay attention. Who cares if one of my hundreds of passwords gets hacked?

LastPass is somewhat vulnerable, but the architecture of LastPass plus the professionalism of the team means that any threat will be seen coming by anyone paying attention, as reports of an exploit out in the wild. A few people will be caught flat-footed but not everyone.

When that happens, we can take steps to mitigate. If worse comes to worst, I can download a copy of the database, change the most important passwords so they're not in the online database, Gmail, banking and such, manage those manually, and hope my database doesn't get hacked.

If it looks like it's just getting worse and worse, I can spend an evening changing passwords and migrating to a self-hosted solution.

My data is safe in that an adversary would have to break through my personal defenses to get at it. They're not sitting in plaintext on some corporate server somewhere waiting to get hacked.

> PasswordSafe has better looking cryptography, though still not up to where I'd like it to be as well as a worse UI, worse browser support, etc. And last I checked I think Linux support was sketchy.

PasswordSafe is, I think, the current best-of-breed with respect to its crypto. Like you, I have some concerns with it (notably the use of Twofish rather than AES, and a too-low PBKDF2 default), but it's the best you can get without writing your own.

It seemed to run ok in WINE last I tried it, and there're one or two native Linux programmes which can read & write its files.

These days I just use an org-mode file encrypted with gpg: emacs automatically prompts me for my password and decrypts it when I open it up.

> So I'm about to take KeePass, gut the crypto, replace it with simple scrypt and AES-OCB or chacha20-poly1305 and hope I can wind up with something I'm comfortable using - anyone have a better suggestion?

Replace the crypto and data model with a PasswordSafe 'v4' format: scrypt plus AES-GCM plus chacha20-poly1305.

I've used my passwordsafe v3 db with

  * password gorilla https://github.com/zdia/gorilla
  * pasaffe https://launchpad.net/pasaffe
  * passwdsafe (android) https://play.google.com/store/apps/details?id=com.jefftharris.passwdsafe

I like a password db format which is portable to different manager implementations on different platforms, and think that passwordsafe v3 is probably a bit better than the keepass format.

(EDIT: and I don't care for integrations with browsers or anything else, they're a bad idea...)

Take Schneier's advice and write down your passwords: https://www.schneier.com/blog/archives/2005/06/write_down_yo...

I suppose this is a problem if someone breaks into your home and gets into wherever you keep your notebook and steals it but frankly that's hardly the only problem you have in that scenario.

I think this paired with LastPass would be great. Email and Banking all on paper with a backup at home. Everything that only has my credit card info and my address can be done through a password manager. Because in my mind those can all be recovered through email, and easily opened through LastPass.

Also that advice is from 2005, I wonder if he'd agree with what I said above or disagree.

Frankly I don't think anything has changed since then that would change his advice. If anything it seems more sensible than ever.

> We're all good at securing small pieces of paper.

Not true, as it turns out. I created passwords for my users and put them on a laminated card as a courtesy, with instructions to keep it in their wallet, purse, etc. They were turning up stuck to keyboards, shelves next to desks, etc. Some people are really crap at securing small pieces of paper.

I'll bet you if it were the details to their own bank account they wouldn't do that! It's a problem of how much people care, really (or how much they think the organization cares).

I think Schneier's (and my) mistake was assuming people know to value their passwords. It's getting bad when the Head of IT, however, is one of those sticking the password to his desk :(

Next time also print their SSN on the cards, or something similarly private they wouldn't stick on their keyboards :)

I have 363 sites in my LastPass vault... I'm supposed to write these all down?

Even if you assume many of those sites I don't use anymore, we're still talking a shitload of passwords I'm supposed to have written down somewhere.

How many of these sites actually need secure passwords? How much would anyone gain by e.g., impersonating one on a forum site? If that number is close to zero, one could just use the same "standard" password for all low-security-value sites and be done with it. For other, slightly higher-value sites, one could leave one's devices logged in as long as practical, and generate a new 15-character password every time one must use the "forgotten password" email-a-capability-URL feature. For the designated secure email account, and maybe for certain financial sites, one might need to remember or write down a passphrase, but there will be fewer than 363.

I've got over 700 passwords in my 1password database, am I supposed to carry a giant notebook with me 24/7 in case I need any of those?

I think this is bad advice - it encourages password re-use, and gives insider threats a perfectly simple vector for credential theft (because you need passwords at work as well as at home).

I use Password Store -- uses git + gpg to store all of the passwords. It makes it really easy to maintain a synchronized password store across multiple devices including Android

http://www.passwordstore.org/

The cryptography in gpg is less than optimal for this purpose and I have to admit I just don't like gpg because it's so big and supports different ciphers, big codebase means more exploitability. But it could work for this purpose, it just seems really inefficient to me.

Is there browser integration or a better UI for it?

Using GPG means that Password Store is less than 600 lines of bash at its core (minus emacs, completions, so on). http://git.zx2c4.com/password-store/tree/src/password-store....

GPG is maintained, and well. Even as it supports different ciphers, that attack doesn't apply here. And very little functionality is accessed through this script.

If that's not a tiny attack surface, I don't know what is.

Password Store might be tiny but GPG itself is a huge attack surface - that's the problem.

Maintained, yes, well... I'd question that. I don't think it's very heavily reviewed or anything, and vulnerabilities pop up in it quite frequently, enough that I'm uncomfortable using it for serious purposes.

https://www.cvedetails.com/vulnerability-list/vendor_id-4711...

Many of these vulnerabilities have to do with very important cryptographic code... If you're comfortable with it, that's fine, it's not a bad solution. But personally I'd honestly be more comfortable with plain text files and TrueCrypt, which has no real cryptographic problems even after quite heavy review, the best we've found is a privesc bug in the Windows driver.

You have linked a list of vulnerabilities dating back to 2006, 10 of which are worth talking about. That's just over 1 per year. Only one allows arbitrary code execution.

Privesc is bigger than all of these combined, especially in a kernel driver.

If Snowden can use GPG, so can you.

Getting root or SYSTEM on my machine is no big deal when all the valuable data you can have is already available as my user. Privesc is minor to me, but it depends on your threat model of course. If you're in a shared environment without VM isolation, it could be a much bigger issue for you. I don't mean to downplay it as you're right, kernel mode privesc is bad, it just happens that it's a minor effect on my threat model for personal systems.

Arbitrary code execution that say, a cloud storage provider could modify would be a far bigger problem. Some of the cryptographic issues are also arguably bigger problems for practical usage. As such, to me, GPG is not nearly as worthy of trust as other, far simpler platforms.

> Snowden can use GPG so can you

This just doesn't make sense as an argument to me - one guy who needed strong encryption used it once therefore you should use it forever and ignore or don't try to develop simpler alternatives?

1 vulnerability that's "worth talking about" per year is enough to make me want to run the other direction, especially on something as sensitive as a password manager.

VM isolation? Now that's an attack surface.

Don't get me wrong, I love to take a dump on GPG as much as the next guy, but this argument is a little misguided. If you're decrypting password files that come from a malicious party, you have a pretty big hole in your security model.

Cloud synchronization is a very common use of a password manager. Many people load their password manager files onto Dropbox, GDrive, etc. Assuming authenticated encryption is properly used and care is taken to avoid leaking metadata, this should be a non-issue.

Solid point. Indeed, that should be safe.

https://github.com/burrows-labs/pz

68 loc

Nice work! This is a very neat spin on the idea. I'll definitely give this one a try.

edit: although, what happens if the dictionary is changed? It's the same on all Macs, but what about trying the same script on Linux?

The dictionary is only used once to generate master password. Then it derives site-specific keys with PBKDF2 from it. You can skip pz-master and use your own master password, but make sure it has enough entropy.

@burrows: I think there's modulo bias here: https://github.com/burrows-labs/pz/blob/master/pz-master#L11 It probably doesn't matter much, but the displayed entropy estimate won't be exact.

You're right; thanks.

What if you need to change the password, store gmail.com.1? how do you remember which one you are on?

Indeed, that's the reason I stopped using my own password generator and switched to password manager. (Also, sometimes I can't remember my username, so password manager is more helpful.)

Nice! I also wrote my own stateless password manager: https://www.npmjs.com/package/viridium

It handles changing a password by keeping a file of the salts, which is theoretically safe to post to a public github (mine's in my dotfiles repo, though it's a private bitbucket repo)

Replying to my own comment because I can no longer edit:

Looks like KeePass guys are going to add Argon2 and have already added authenticated encryption.

Keep an eye on it. Might be worth moving to.

http://ehc.ac/p/keepass/discussion/329220/thread/a48066c0/?l...

KeePass is open source. If you feel like you can do a better job in certain aspects, please consider sharing those changes so that others can benefit.

Of course, any eyes I can get on that sort of cryptographic code are invaluable.

Applied cryptography is easy to fuck up, as we see time and time again.

I'm seriously hoping someone gives me a better solution though, it'd be very nice if somebody had just done this right from the ground up.

Self-serving, but I'm working on an open source project which handles password storage using AES using symmetric key with the website password (many other features): https://github.com/myplaceonline/myplaceonline - you can run this locally or test out the beta version online (email me)

Specifically: https://github.com/myplaceonline/myplaceonline_rails/blob/af...

Dropbox seems less than ideal, how about intergrating these three tools?

http://www.passwordstore.org

https://ipfs.io

https://github.com/larsks/git-remote-ipfs

as an easier to use alternative to ipfs, look into syncthing

Wow, that looks amazing.

I currently use LastPass, and I previously used KeePass. Now I'm looking to move away from LastPass, post acquisition.

I've considered storing text files containing passwords inside of a VeraCrypt or TrueCrypt volume. Or storing the KeePass database file similarly.

Any feedback on if this is a bad approach and why?

It's not a bad approach - it lacks integration, it's easier for malware to grab, but that's about it. Malware can already dump the memory or log the keyboard and mouse to grab what'd be needed to decrypt your LastPass or KeePass, so in the end those solutions are no better than plain text files inside an encrypted container. The lack of integration, generation and other UI niceties is really the biggest loss I think.

Well, WRT to malware, KeePass can somewhat mitigate generalized threats. Say, in-memory encryption to protect against memory dumps, using a secure desktop [1] for the master password, and typing obfuscation during auto-type to protect against keyloggers. Well, keyloggers that aren't written with KeePass in mind, at least. Both of those would give it a modest edge over plain text in an encrypted container.

[1] http://keepass.info/help/base/security.html#secdesktop This said, both secure desktops and auto-type obfuscation are turned off by default...

The whole "secure desktops" thing is a bit of an oxymoron too. If you can gain admin privileges you can steal any desktop and session token you want and keylog it. I've used that trick before to keylog winlogon's "secure" desktop, so surely KeePass would be similarly vulnerable?

Additionally a quick patch or in memory modification of KeePass.exe would easily bypass any protection like this, lookup the KeeFarce tool to see an example. I'd hardly call this an "edge" over plain text files in an encrypted container, considering it does nothing to actually prevent exploitation but simply provides a form of security through obscurity.

Ultimately once a system is infected, all you can do are half-measures and will wind up worthless against even a mildly sophisticated attacker. Unless you run the software in a separate machine, you're dead in the water and it's pointless to discuss what happens post-infection when anything is really possible.

Well, KeePass.exe is signed, which prevents the malware replacing/modifying the exe. I personally run it as Admin and lock my keyfile down to admin accounts, which prevents against an un-elevated user process from stealing anything of value.

I guess if the malware get's admin access I'm hosed, but that's pretty much game over anyway.

> Well, KeePass.exe is signed, which prevents the malware replacing/modifying the exe

Windows doesn't require executable to be signed, strip the signature from the PE file and unless the user verifies it they're still dead in the water. Not good enough? Okay, install a new certificate for code signing the patched PE file and sign it yourself.

As for user isolation, it's a great idea but you could take advantage of this isolation with the filesystem method too simply by making the files only readable by an administrator and running a text editor or search tool as an admin so I'd still say this is not an advantage over the encrypted disk image method.

EDIT: Cleaned up.

Emacs has integration with GPG, so you can edit an encrypted text file directly.

Why not 1Password?

Similar things have shown that 1Password has even worse problems than LastPass.

Could you be more specific? The only issue I've heard about was that in an old format you could see which sites had saved passwords. That's more of a privacy issue than a security leak.

On second glance it looks like you're right, I mis-recalled, they had a problem with the old DB format that's about as bad as LastPass has now. KDF they're using isn't the best, on par with LastPass and it looks like they're using authenticated encryption and everything... so overall, not so bad.

It's another magical proprietary solution though so I can't help but feel like switching from LastPass to 1Password wouldn't be worth the hassle. I'm looking for something more in the open source and dead simple direction.

What I like about 1password is they are proactive and explain their crypto process extensively. They're also small, in Canada and 1password is their only product, so the conflict of interest risk is lower.

There are scripts out there that will take your lastpass dump and convert it into a 1password import file. The process to convert over takes about 30m-1hr.

I'm curious. What are the sketchy parts about KeePass's cryptography?

Main thing I don't like is their custom AES-based key derivation function. I'm also not sure if it does authenticated encryption but if I recall correctly it does not. I'll have to have a look at it again soon.

I agree about the key-derivation (just use the PBKDF built into .NET dammit), but I've checked out the code, and it looks sound. It uses standard Windows crypto libs when running on >=Vista.

As to the auth'd encryption: they do that above version 2.2 http://keepass.info/help/kb/sec_issues.html

Thanks, I'll definitely be keeping an eye on keepass, there's a post around indicating that they're going to add Argon2 (the winner of PHC) when it's finalized. I might just do the switch now...

Thanks for pointing out these issues.

Authenticated encryption seems to get popular just these last couple years. Besides injecting unwanted data into the encrypted data, what other attacks can be done with it? For encrypted code, injecting unwanted code in the middle of it would be a big problem when decrypted and run. For pure data file like the the password database, would it be just adding extra garbage?