Hacker News Reader

Comment by AdmiralAsshat | Hacker News Reader

See quite a few nods to 1Password in here, which is good, although I tend to favor KeePass myself, given that it's FOSS.

It also has a way better Firefox add-on than any of the others I've seen (which is my main browser), and the Android apps, if unofficial, aren't bad either [0]. Importantly, they feature the ability to either pull from a local Keepass DB or to get it from a connected Google Drive account. I've taken to using the latter to make sure my database is synced across all my devices.

At this point it works fairly well across everything I use, with the one exception that trying to keep the database synced on my Windows box requires an extension that looked a tad shady to me [1], so I opted to simply manually upload a new version each time instead.

[0]: https://play.google.com/store/apps/details?id=keepass2androi...

[1]: http://keepass.info/plugins.html#kpgsync

View on HN

I don't understand why 1Password's approach to the cloud - syncing via Dropbox or Google Drive - is considered that much more secure than LastPass. If anything relying on Dropbox has always seemed to me to be a huge liability

Dropbox is not the only option. While not officially supported, I sync 1Password just fine using BTSync in local mode (no tracker, no relay).

Sure, it's kind of a pain (I can only sync on my home network) but worth the trade off to me. I mean how often do you have to sync passwords?

Add a VPN and you can sync from anywhere :)

Consider using dynamic DNS for a central home server and predefined hosts in your mobile devices or laptops.

I think I did set this up but was not working for some reason. However, it's not a high priority item to debug.

It's a matter of target payoff. Dropbox, Drive, etc. are not specific to just storing password DBs.

If my account is compromised, the attacker has one DB for their effort. If a cloud storage is compromised, the attacker has to scan through everything looking for DB files.

LastPass cloud storage is meant only for storing password DBs, so an attacker knows that within a single target lies a large trove a specific type of data.

I don't understand this. So LastPass could increase their security by including a bunch of pictures of puppies in their folder for me? Why not do it then?

I don't really buy it but I've heard the theory expressed that LastPass is more of a target because an attacker knows that a compromise could get millions of valid logins but something like Dropbox is less of a known quantity with more things to sift through.

I'm skeptical that a) our hypothetical attacker couldn't search for files to get all of those synced 1Password files or b) that such a complete compromise wouldn't turn over enough interesting personal docs to make the potential resale value quite lucrative – “They got my tax return but fortunately not my nytimes.com password!”. In either case, pure worst-case analysis isn't terribly useful without some concept of relative likelihood.

If one were looking to steal a bunch of jewelry, would it make more sense to hit a jewelry store or some large shopping mall?

There are several ways to expose data on dropbox as the result of human error that don't apply to lastpass

According to other comments here, your LastPass master password is used both to encrypt your stored passwords and as the password to log into their cloud storage. So someone compromising the login processing would also get the keys to the password encryption for the compromised accounts.

With 1Password and Dropbox the 1Password master password and the Dropbox login password should be unrelated. My Dropbox password, in fact, is a long password generated by 1Password's password generator. If someone gets a hold of it by compromising Dropbox, they might then get a copy of my encrypted passwords, but they get no clue to my 1Password master password.

There is some unencrypted non-password data in 1Password's data, so I'd not be happy if Dropbox were compromised, but it would not be a disaster.

I use it with a private BTSync network that I control completely.

If you wanted security, you'd use a SHA256 hash of a master-password + domain name.

http://angel.net/~nic/passwdlet.html

Storage is unnecessary. LastPass, 1Password... every one of them has centralized storage. No one needs a central server, but a central server is the only way a "service" can sell itself.

There are multiple problems with this approach. SHA is way too fast, some site is always going to have Auth requirements that won't be the same as the ones you have set (one service wants mandatory special characters, one wants mandatory alphanumeric only), and, most importantly, you can't change the passwords unless you change the master password and remember which you used where.

Fair point. But proper key strengthening is a well-known solution to this well-known problem. The general methodology of using password-safe hash + master password + domain name is useful.

As you note, SHA isn't appropriate for this purpose. PBKDF2-strenghtened SHA, SCrypt, BCrypt and other functions should be used.

I agree, I wish browsers performed some key strengthening built in.

How do you generate a different password after that one's been found to be stored in plaintext and the admin resets all of the passwords?

Or, and more to the point, having generated a different password how do you remember which sites need a V1 password and which need V2?

When sites introduce silly rules around password structure, how do you make sure your passwords conform?

And even if you could guarantee you'll never hit any of these issues, shouldn't you be using a key-derivation function, rather than a hash?

I entrust my passwords to KeePass, as I trust its authors to have more of a clue than me and it lets me store arbitrary data rather than restricting me to a specific class of generated password. That file can then be replicated to enough of my devices that it's available when I need it, without a third-party having enough access to the data to be able to issue even the kind of security alert we see here.

> Or, and more to the point, having generated a different password how do you remember which sites need a V1 password and which need V2?

> When sites introduce silly rules around password structure, how do you make sure your passwords conform?

Store _THESE_ rules in a central database. Not the passwords. Those rules can be public at no cost to security to the end user.

But LastPass, KeePass, OnePass and all sorts of Password generators store the actual friggen password, instead of salts or public information (like "5th password on gmail")

I like this idea. I think I'll try this out for all those random dumb websites that want passwords.

You linked to the old version btw. Updated version is here: http://angel.net/~nic/passwdlet.domain.html

I use LastPass to also store the username I used, which is handy given that:

1. Some sites use email, others use username (and sometimes your usual username is taken), and a handful of sites assign you something (eg: with an old VoIP provider I used to use, I had to log in with my customer number instead of a username)

2. I use a unique email address on every site, in the form "domain-i-am-logging-into.com@something.mydomain.com", though occasionally I have "companyname@something.mydomain.com" (eg: I use "amazon@" because I my account works with both amazon.ca and amazon.com)

LastPass remembers all this crap for me, and it also lets me keep other notes, password history, etc, as well as being quite convenient.

http://crypto.stackexchange.com/a/5691/291

I've considered this before. It's a nice idea, but it suffers due to the arbitrary length and complexity requirements that many sites place on passwords.

I've actually got a very basic solution to that.

Use lowercase hexadecimal as the "baseline" password. From there, truncate to the length requirement, and add symbols to the end to guarantee complexity requirement.

For example, "masterpass gmail.com" will md5sum to "194b52e5". If a password requires symbols, add a "!" to the end. If it requires a capitol letter, add "A" to the end. Add in the order of "number->letter->symbol". So... a site that requires numbers, capitol letters, and symbols would be:

"194b52e51A!". (The hashed password, followed by '1A!')

That does't sound simple, because I'm not going to remember the site specific password requirements for each of the 250 logins I have within my password manager.

I have a sftp account on my server for my keepass data, I can sync it from anywhere and I don't have to worry about google drive having access to my (encrypted) data. I like it.

Is there any solution for keepass on ChromeOS (I mean other than the whole developer mode/crouton thing, I prefer to keep ChromeOS in secure mode)?

For my Chromebook, I use a chrome app called Browsepass. It's still pretty rough, but it at least lets me open the KeePass database:

https://chrome.google.com/webstore/detail/browsepass/pihdapf...

Which extension do you use for that?

He might be using the IOProtocol Extension: http://keepass.info/plugins.html#ioprotocolext

That's the one.

So you're trusting Google?

The KeePass database itself is encrypted with a Master Password/Password Phrase. You can take a look at the encryption they use for it here:

http://keepass.info/help/base/security.html#secencrypt

Hence, I am reasonably confident that even if Google were to turn over my Drive account to the NSA, they wouldn't be able to crack open the database.

See also: discussion on feasibility of brute forcing a KeePass database:

https://security.stackexchange.com/questions/8476/how-diffic...

That's no different to how LastPass stores your vault on its servers, isn't it? They're just using their own cloud instead of Google's.

There actually might be a difference in favor of LP. LastPass knows, semantically, what encrypted password archives are, and can monitor for statistically unusual traffic related to an attacker downloading them.

Google has no no way to know, if 10k people are storing their encrypted keepassx archives in gdrive, and if those 10k archives are accessed in rapid succession, that it's an attack. It's lost in the noise of gdrive traffic.

That blade cuts both ways: the keepassx archives would be lost in the noise of all the other files on Google Drive/Dropbox/etc. On Lastpass, you know you're getting password archives. To me: advantage KeePass.

When thinking about security who has more resources and expertise? LastPass or Google?

It depends on your threat model. If you are more afraid of the government than of a random script kiddie, the vastly bigger resources of Google do not matter as your (encrypted) database is just a NSL away.

And then the NSA is trying to crack it </tinfoil hat mode>

Well if I put on my tinfoil hat, then there is no protection from the NSA. So, now I'm only trying to protect my password/identity from criminal elements, I tend to side with Google as knowing what they are doing. It doesn't mean they will also be mistake free, but it is something they deal with and have been dealing with before LastPass was even an idea.

When you've put your passwordfile in the cloud, you should assume it's fallen into the wrong hands (NSA) already.

I've put my keepass file in the cloud for extra backup, and I know I can only rely on its cryptographic strength to keep it safe.

The point of using a locally-encrypted password database like KeePass is that you don't have to trust Google (or DropBox, or Microsoft). You trust the encryption instead.

Reply on news.ycombinator.com