Just so we're clear: your assertion is that because the password generator uses a non-cryptographically secure PRNG, generating unique 20+ character alphanumeric passwords for every login is worse than people's default behavior?
I mean, I get that it's worse than other keepass implementations - that's obviously a problem - but if this gets people to stop using "hunter2" or "p4$$w0rd" that's got to be worth something, right?
No, it's not worse for your scenario. (That wasn't my assertion)
However, this is an alternative to KeePass/KeePassX, so the typical behavior of KeePass users is to generate passwords with it, not reuse bad passwords.
For example, I use KeePassX to generate strong passwords for long-term encrypted archives, and if I switched to this app, I wouldn't get the same security.
I'm confused, though, should I say: "All right, people, fuck it, generate your passwords with Math.random! YOLO!"
I use KeePass and I don't use it to generate passwords. It's a pain to open and close every time I need to login somewhere, especially if I'm on mobile. I use it for when I forget my passwords, and I honestly believe that is the common use case, but who knows?
I hope that's not a common use case (among the technologically literate). I would expect said individuals to have far more passwords of sufficient length and complexity (not to mention duration) than could reasonably be remembered.
Lastpass, being primarily a browser plugin, makes generated passwords much more convenient. When I'm setting up a new account, I press Alt-G to bring up the generator dialog, and then it auto-fills when I need to log in. I honestly don't know most of my passwords (I still memorise my primary email password, so I'm not totally stuck if I lost access to LastPass).
This is a compromise, because I'd prefer to trust an open source tool and an encrypted local file, but I trust Lastpass enough, and the convenience is very nice.
There's addons for Firefox (KeeFox) and Chrome (ChromeIPass), making the UX of KeePass pretty much the same as of LastPass. I've switched about a month ago and am happy.
There's addons for Firefox/Chrome as well as apps for Android that enable autofill and other stuff you might expect from a modern password manager (making the UX pretty close to LastPass).
I've been pretty happy with keepass2android's keyboard integration. It avoids the clipboard entirely and helps autoselect the right password and username if you let it. It also supports using a HOTP NFC token in conjunction with the master password.
I know it doesn't add that much security since a determined attacker could still brute force the OTP with the way it works but it keeps out the casual attacker that's not that savvy.
The intent of KeePass is generally to let it generate sufficiently strong passwords for you, and a way to store those passwords. It's probably a bad idea to store passwords you've devised in it, because then you're not getting any additional security.
I use KeePass across a range of devices, including my phone and laptop. I keep the dictionary synced with Syncthing.
I use it regularly to generate new passwords for websites, refreshing old website passwords (hello Heartbleed!) and logging into existing accounts. I also lock down the security questions so they can't be guessed. I'm now logged out of most services by default, especially banking, and the dictionary auto-locks after a short time.
Once I accepted a small price of inconvenience in setup and use, it has a positive impact. Now I remember only one password and updates are kept in sync across all my stuff.
Yep, I use KeePass primarily for password management, in most cases I don't control what the passwords are - how else am I meant to store all these different client VPN credentials?
Security experts are really bad about explaining their positions. I don't doubt that you are right, but can you lay out the scenario for me where my Reddit account will be hacked because I used Math.random() to generate the password?
Hmm, I tend to think of KeePass as a manager for passwords for accounts, services, etc. I hadn't considered storing archive passwords in it, or are you only using it to generate them? It seems like pwgen would do that fairly well...
This is the question I ask every single time I read about anything in security. It feels like there's just SO MANY THINGS wrong about every damn thing now the only way I can figure out what I have to really worry about or focus on is anything with a PRACTICAL attack that's easily automated and remotely exploitable.
Cryptographic attacks become better, some of them become practical. RC4 attacks were not considered practical until recently, and now everyone runs with their heads on fire replacing it.
The best answer is to listen to what security people say. When they have a practical attack on something it is already too late.
Security experts, by in large, only care about academics and care very little about usability, so I do not trust them unless they give me specific scenarios where I am in danger.
Just to clarify what I mean; we have to make decisions based on tradeoffs. Having the most secure password possible is not the only thing that matters. So "trust security experts" is not a good response; I need to know threat levels so I can make informed decisions. I'm not just going to do the same thing a security enthusiast does because I value different things, to different degrees.
Looks like you didn't understand the sadness of the issue I was reporting. The author of the software constructed his own random number generator from two primitives: Salsa20 stream generator and Math.random. The last part is what makes this PRNG theoretically insecure: because Math.random is not guaranteed to give cryptographically secure random numbers, thus, theoretically, the generated passwords can be guessed. (The fact that there are no current attacks on current implementations of Math.random in browsers doesn't mean that we won't get them in the future.) The secure alternative to author's PRNG is ~one line of code: window.crypto.getRandomBytes. There are no tradeoffs involved! On the contrary, the author's insecure construction is more difficult to write than the secure one.
(BTW, while we here argue about security experts, the author said "Thank you, I'll replace it of course.")
This is what I'm talking about. You, a security enthusiast, are only interested in the technical security details. You respond to a comment about tradeoffs with details on the bug.
I don't care about why the bug happened or how easy it is/isn't to fix. I care about whether the existence of the bug is something I should be so concerned about as to not use the software. In order to gauge that, I need a little more info about the threat level.
>I don't care about why the bug happened or how easy it is/isn't to fix. I care about whether the existence of the bug is something I should be so concerned about as to not use the software. In order to gauge that, I need a little more info about the threat level.
Threat level is 0%. No currently known attacks exist. This threat level immediately goes to 100% when a practical attack is discovered. There is no guarantee that a practical attack exists that hasn't been brought to academic or mainstream attention (e.g some cracker has a practical attack that they're keeping under wraps). By the time the threat level hits 100% the cracker may have already broken into your account(s) before you even hear about the attack.
Therefore when something is shown that "attacking it is possible" you can make one of two assumptions
1) No practical attack exists and you'll be safe until it exists
2) A practical attack already exists and it is only a matter of time until you get pwned
Rather than worry about whether or not a practical attack already or will one day exist, I'd use cryptography that hasn't been shown to be broken.
This comment doesn't make sense. All attacks are not equal. Some require physical access; some do not. Some require seed data; some do not. What exactly are you talking about here?
This is why security people are so frustrating to talk to; you only talk in extremes.
> Rather than worry about whether or not a practical attack already or will one day exist, I'd use cryptography that hasn't been shown to be broken.
That's not what I'm worried about. I'm worried about given that they do exist what is the risk to me? What is the likelihood that my account has been broken into?
>This comment doesn't make sense. All attacks are not equal. Some require physical access; some do not. Some require seed data; some do not. What exactly are you talking about here?
I'm not a security expert, more of a hobbyist. So I'll let someone else quantify potential specifics. To my understanding, they would not require physical access and would be able to guess any passwords generated (once an attack has been found/created).
>That's not what I'm worried about. I'm worried about given that they do exist what is the risk to me? What is the likelihood that my account has been broken into?
The chances of 0 becoming 1 are not quantifiable because it requires knowing unknowns. It is, however, non-zero. For a small list of unknowns:
1) Who knows about the attack
2) How practical is the attack?
3) What software/websites/people are they choosing to attack
4) Are you even using any of the software/websites that are being attacked?
5) Are they going to accept cracking <10%~ accounts if they can do so in <24 hours or is their goal to crack >50%~ accounts? Many crackers only care to scrape the bottom of a barrel. What are the chances you were in the part of the barrel they scraped?
I assume the worst because being compromised is a zero-sum game. I've been compromised or I haven't. Therefore my variables are:
Everyone. Extremely. Only things I use. Of course. Doesn't matter, I'm in the targeted group.
I wouldn't make any bets on security through obscurity.
Getting my reddit account hacked is not the end of my life. Hell, getting my bank account hacked is not the end of my life. I don't want those things to happen, I will take precautions to prevent it.
But too often security people talk as though it's the only thing I should care about. And it's not, I care about other things too, to varying degrees.
So, to make an informed decision, I need to know more than just that Math.random() is insecure. Knowing that an attack wouldn't require physical access is the type of information I'm interested in. So thank you for that.
I understand completely. I feel most people's threat models stop even before 'threat has physical access'. The chances of both your computer being stolen and the person who stole it being tech-savvy enough [0] to break into things may as well be 0 for anyone who isn't the target of a state actor or working in a security field. At that point the only people who care are the people who care about security or slim chances like that occurring. :)
[0] Or the thief selling it to someone who is tech savvy enough. Still practically 0 for most everyone.
It's (relatively) easy to verify a software against a strict security definition and decide if it meets the definition or not.
It's incredibly difficult (I'd say "impossible", but I'm being pedantic for now) to check a flaw against such strict definition and check it against all possible use cases and all possible inputs and decide if one of them will lead to bad consequences.
Thus, if there's any practical attack? How the hell would I or anybody else know. We can only know a resounding "yes" after you get owned, nobody can ever tell you a honest "no" to this question.
I feel like your conclusion is the opposite of proper.
Proper would be: don't roll your own crypto, use what professionals created, and only in the way they document it to be used. When in doubt, email tptacek or another professional he would point out.
I don't know of any published attacks on XorShift128+, which is used in most browsers for Math.random. What I know is that it's not a cryptographically secure PRNG, though, so all you have to do is sit and wait for one ;-)
> The RandomSource.getRandomValues() method lets you get cryptographically random values. The array given as the parameter is filled with random numbers (random in its cryptographic meaning).
> To guarantee enough performance, implementations are not using a truly random number generator, but they are using a pseudo-random number generator seeded with a value with enough entropy. The PRNG used differs from one implementation to the other but is suitable for cryptographic usages. Implementations are also required to use a seed with enough entropy, like a system-level entropy source.
This is awesome. People are obviously going to give you a hard time about security and your implementation of the important parts of the software, but that's the advantage of open source!
Edit: I am a daily user of KeePassX and get really tired of the UI after a while so I will definitely be trying this out ASAP!
A warning about Macpass: After I saved my Keepass database with Macpass, KeepassX couldn't open it any more. So keep a backup unless you're sure you want to switch permanently. This probably applies to switching from any password manager to any other, honestly.
(I think I was able to fix it in that case by opening and saving it with Keepass.)
I think 2.0 fixed a lot of things, but the interface is still pretty painful (my opinion). Still usable of course, like I said I use it all day every day.
Haven't tried MacPass but it looks great and I will give it a whirl. Thanks!
One issue I have with pass is that it leaks meta-data about what you have stored. The contents are encrypted, yes, but the filename identifying the content is sitting right there in the open.
Check out this similar gpg-based password manager, which uses just one encrypted container for improved confidentiality - https://github.com/drduh/pwd.sh
I've previously looked into this and stopped half way through migrating my lastpass. I have a rather naive question: For the replication across devices this tool relies on git, but where are folks setting up the origin?
I host mine on gogs.sr.ht, a private git service I run for myself and friends. I used to host it on a private GitHub repository. There are other options like a private Bitbucket repository, or even just a public repo on GitHub - since the passwords are all encrypted, you don't really have to worry about that.
I'll happily give an sr.ht account to anyone who wants one for this purpose, mention HN in your application comments: https://sr.ht
The reference implementation's domain is vulnerable to MITM attacks between KeeWeb and CloudFlare until they set their CloudFlare crypto settings to "strict" and get some real certificates of their own (e.g. Let's Encrypt).
Of course exploiting this would be very difficult, but it is possible to MITM the connection between the CloudFlare proxy and GitHub pages as long as keeweb.info continues to not use DNSSEC.
According to their FAQ[1], maybe. They test integration with KeePass, but it should work as long as you're using the .kdbx database format (KeePass v2.)
The latest version of KeePassX is using the same database format as KeePass2 and this app, so you should be ok. If you are using older (KeePass v1 compatible) format of the database just upgrade it in the lates version of KeePassX, it will convert all the data for you.
This looks awesome. My only gripes with KeePass is the confusion between KeePass,2,X etc; get it together guys. Also there is a serious lack of good browser extensions. There only seems to be one offering and its the clunkiest thing I have ever used. -- That said, as soon as the second problem is addressed, I'll be switching as soon as possible. I'd love to move off my proprietary solution to an open one.
I don't know about this version, but keepassx creates a file in the same directory where the password kdb file is, and use it as a lock.
But, keep in mind that dropbox can delay updates to the server (could be hours if you are disconnected) with no warning to the user, which means that two different users could update the same file independently and create a conflict. For this reason, it isn't suitable as an enterprise solution.
Having said that I recommend dropbox as a poor man escrow, so that somebody you trust as easy access to all your passwords for banking, social network (keep your alt accounts somewhere else :-) ), servers' root, etc...
Yep, aware of how KeepassX does this. Its better than some (i.e. there are locks at all) but dropbox doesn't always cooperate. Have been looking for a better solution, but most seem to not even do the lock file thing.
This. Reading KeePass database is simple. The problem with KeePass is that its sync protocol is undocumented and reportedly arcane. And just syncing opaque blobs at whole will eventually lead to data losses.
That's pretty nice. I'm going to look into packaging it for myself for FirefoxOS. My only issue with it right now is aesthetic: the top item (search box on the main page, "< back to list" in entries, etc) scrolls off the top of the screen, leaving that much blank white space at the bottom of the screen. I'm on a ZTE Open C running the nightly version of FxOS from http://builds.firefoxos.mozfr.org/doc/en/devices/zte-open-c-...
Yes, my only phone is FxOS. No, it's not good enough. I'm sure if I was on better hardware, it would be okay. My only requirements for it are a) decent web browser (it fails on this point) and b) Google 2 factor auth (I'm using GAuth[0]). I really don't care about playing games on my phone (I have a hacked PS Vita for that) and I have a laptop for everything else.
Does there exist an enterprise grade server/webui solution based on a keepass db? We are looking for an enterprise password manager solution that does not need all the ldap/ad integration bells/whistles (although we may explore ldap integration with the tool in the future). So I was thinking why not just use keepass. And by enterprise grade I guess I really mean it needs to be a multi user solution, but everyone would be working from the same pw db..
The title should probably be "KeyWeb - a KeePass Web and desktop client" to be clear that this is not the official KeePass client. I was briefly concerned because I generated many passwords with KeePass, but this post is about a different piece of software.
Just built this, looks good so far. Being a totally blind back-end developer I've wanted to look at web accessibility, while the app is accessible I think it could be made better so hopefully I can use this as a way to learn.
Excellent work! Clean, beautiful and works out of the box.
Is there any way to have a system-wide shortcut to auto-enter passwords? In KeePassX it's called "Global Auto Type Shortcut". I just can't live without this ;)
I'm not sure about "big", it all depends on how much you trust 1password and what your threat model is. For me, the advantage of keepass is that I don't need to upload my credentials anywhere, or trust some closed source blob running in the browser, etc. It has a XML format that enables things like this client to be created.
1password has the advantage of excellent platform integration on iOS, and various browser extensions with auto-fill.
I use my own script to generate passwords. I don't store anything beyond a salt. The password is just a hash of the website name, the salt and a master password. Then I just copypaste the result. Simple is best.
Is there a name for this kind of scheme where you can generate a password every time because you have all the parts needed? I've been seeing that people do this but don't have a name for it.
> the advantage of keepass is that I don't need to upload my credentials anywhere
But if you want to sync your credentials across devices, you still have to upload them somewhere, right? Doesn't this just support sync via Dropbox? If so, aren't you then just playing the trust game between two third-parties?
You are uploading a file that is encrypted using very strong encryption, not plain text password.
An employee of that company, or if the file was leaked due to technical errors, a member of the general public won't be able to decrypt it. If one of the richest governments wanted to, they might be able to, but if you had reasons to be a target you'd know better than using this.
Is strong-encryption something that 1password is fundamentally opposed to, or something they just haven't implemented yet? If I'm going to switch, the answer to question is pretty important.
I work for a competitor of 1password, and as far as I know 1password is one of the "serious" password managers and I really doubt they would store data unencrypted.
Last time I checked, they did not offer cloud sync directly, but integrated with dropbox to store your encrypted vault.
Not really sure what the previous comment wanted to imply.
cmrx64: it all depends on how much you trust 1password and what your threat model is. For me, the advantage of keepass is that I don't need to upload my credentials anywhere
oneeyedpigeon: But if you want to sync your credentials across devices, you still have to upload them somewhere, right?
dorfsmay: You are uploading a file that is encrypted using very strong encryption, not plain text password
I took that to mean:
(with keepass) you are uploading a file that is encrypted ... not plain text password (as for 1password)
No, but my understanding is that with 1passsword and similar service the web client sends the password in unencrypted form to the server. A rogue employee, is even the combination of a bug and a leak would expose your password.
With keepassx, your password never leaves your device in unencrypted form.
This is very much untrue. 1Password syncs an encrypted vault through separate channel (e.g. Dropbox, iCloud) -- it has zero-knowledge of your passwords. It just picks up a big encrypted blob from wherever you store it.
"The easiest way for us to protect your data and data about you is to not have that data in the first place. You may be noticing a theme by now: we can’t reveal or abuse data that we don’t have.
We do not have your 1Password data. We do not know your 1Password Master Password. We don’t even know if you use 1Password. We do not know how many items you have in your vault or their type."
I'm a big fan of FLOSS solutions, but I can't recommend KeePass/KeePassX/... over 1password. There are many people implementing KeePass-related things and most of them don't know much about secure development (nor do I claim to). 1password on the other hand has audits and professional security people. As long as they don't turn evil and give you a bad binary blob, I would bet on your passwords being more secure with them than if you were using one of the KeePass* tools.
Sure, in theory, 1password MIGHT have better private auditing and review. But there's no reason to believe they do. To the contrary, when asked about open sourcing 1password, one of their developers explained that they don't do formal code review because it's too expensive, and that none of the external experts they consulted with have ever performed a full review.
https://github.com/antelle/kdbxweb/blob/906e927d3e3384db4dd3...
https://github.com/antelle/keeweb/blob/master/app/scripts/ut...
(in meme form: https://imgur.com/FcZNflQ)
Filed issue: https://github.com/antelle/kdbxweb/issues/5
(embarrassing/funny: it was me who wrote Salsa20 "user-space" generator used here (https://github.com/antelle/kdbxweb/blob/906e927d3e3384db4dd3...), but it should be properly seeded from secure random number source to be secure. Added this note to the gist where the author found it: https://gist.github.com/dchest/4582374#file-salsa20-js-L1-L1...)