Comment by jjarmoc | Hacker News Reader

Comment by jjarmoc | Hacker News Reader

Parent Full thread

> Maybe there are people out there who will accept much more inconvenience in exchange for avoiding the risk associated with a cloud-based service. But, for me, the inconvenience is simply too much.

Sure, it's a balance everyone has to find for themselves. As you note earlier, a cloud password manager is better than shared passwords.

I'm certainly happy to accept a bit more inconvenience than most. I only do banking on one device, and one device only. I set up per-device passwords for things like Gmail (and MFA for my primary password), I authorize mobile apps via API keys, and try to avoid services that require I use my password on multiple devices in the first place.

For the most part, devices I use frequently can access things I use frequently without passwords. For web services (like HN) I simply don't need to log in and comment that badly if I'm on an unusual device.

> So the choice once more, for me, becomes cloud-based password manager or no password manager at all.

If those are you're options, you're probably right to go with the cloud option. For many people, even a physical notebook of single-service passwords would be an improvement.

> (Though if you've found a good option, that will allow me to easily sync across my home desktop, laptop, office pc, tablet, and smartphone, without using the cloud, I would absolutely love to hear about it! Maybe something Bluetooth based?)

Not really. It's largely the magic of cloud synching that I don't like. A lot of people run standalone password managers like Keepass or 1Password and store the database in some sort of file synchronization service like Dropbox. I guess that's workable, but it's still not something I'm going to be doing.

I simply don't want a single place where all my passwords are available that isn't hardware physically under my control.

> For web services (like HN) I simply don't need to log in and comment that badly if I'm on an unusual device.

You also don't need to use one solution for every use-case. I use an online password manager (LastPass + 2FA) for relatively high-use, low-value credentials (things like web forums and online shopping sites). For higher-value credentials (investment accounts, banking, email), I use an offline password manager on trusted machines and site-specific 2FA when available.

That's been a good trade off between convenience and security for me.

I think 2FA is really the key here. If I have a really physically isolated 2FA device I feel pretty safe actually.

Seconding multiple solutions. I use LastPass to deal with the volume of credentials required, storing most but not all sites. I memorize the most important sites (bank, primary e-mail), never putting them in a password manager.

A solution I have found that (I think) is relatively secure. Setup a keepass database that requires the use of an unlock password and key file. Sync the database to Google Drive but never sync the key file! Only store the keyfile on a locally ecrypted thumb drive or only stored locally on the devices (preferably encrypted) that you need to access keepass from.

In random time/day intervals reset your key file and keepass password.

The key to this method "working" which should be "secure" barring total ownage by a state actor or well funded individual is to never sync the key file and database to the same service. Additionally, sync up a "false flag" key file if you want some additional level of obscurity.

tl;dr:

1) Setup Keepass database to require password and key file to unlock.

2) Sync database to cloud service but never the key file.

3) In random time intervals (t=60+days) Randomly change both the password and generate a new key file for your database.

4) Keep your key file on an encrypted drive or on the device (preferably encrypted) that needs access to Keepass.

I'm concerned (but not qualified to judge) that changing your password and keyfile may not be as beneficial as it appears.

A password for an encryption key is very different to a password for a server. Once you change your password on a server, there's little harm in publishing it -- it can't be used any more. But the key is a file that may still exist (see also Wikileaks' key being published by David Leigh).

Consider: your database exists as a file. If someone is able to gain access to a copy, that copy remains valid as long as at least one password within it remains unchanged. So you need a strong key, because it's subject to offline bruteforcing. Now they get a second copy of your database, with a different password. If any of your passwords are ever published or cracked, your database is exposed. If you have to change your password regularly, it's going to be tempting to make it weaker, or to store it somewhere less securely. If you're using key files, they only need to get one of your files. It seems to me that the more key material you need to secure, the more difficult it's going to be?

Anyone who knows better want to chime in?

I'm also no qualified to judge, but I would say it's important that in addition to rotating the password and key file used to encrypt the password database, one also rotates the all the passwords in the database regularly. This way, if someone obtains a copy of your database, they have a limited time before all the passwords in the database become useless.

This is true, as well as enable 2-factor authentication for sites that support it.

The key it seems to me is by using both a master password and a key file. If a site gets cracked and they find your site specific password that won't help them determine your keepass database master password &/or generated key file that you only store offline and never sync to the cloud.

In order to open the database you need both the correct master password and the correct keyfile. If the attacker doesn't have both, they should not be able to get into the database.

I do something very similar to this, but I sync the key file to a second service (both services have 2FA logins). Keeping it off "the cloud" entirely is indeed safer from a security perspective, but think about how many copies of your key file you have, and what would have to happen to destroy all of them. If you've just got the key file locally on e.g. your laptop and maybe a smartphone, it doesn't take much more than a petty theft to cause you to lose access to every service in the database (in which situation of course you'd paradoxically want access to those services right away!).

> I simply don't want a single place where all my passwords are available that isn't hardware physically under my control.

That makes sense. What would be really nice -- and what I had in mind -- would be some sort of device where the passwords were stored to which my other devices could easily connect to to access the passwords, sort of like a wireless dongle. (Though, really, even the wireless part is negotiable. I'd be happy to plug something in as well so long as it was easy to carry with me and supported the right connectors.)

Seems like a Kickstarter campaign waiting to happen.

Somebody want to make an IronKey for cell phones?

And when the device dies?

If you're using a reasonably trustworthy password manager with a strong master password, your biggest risk is data loss, not mass password compromise. Syncing to multiple devices and cloud backups dramatically reduce that risk while only marginally increasing that of compromise.

I'd make it so that under some very specific and hard to attack circumstances, it would be possible to make a backup of the keyring stored on a device.

Possibly only directly to another device, or maybe dump an encrypted blob to file or straight to paper (bitcoin printable wallet style).

That creates the risk of someone duplicating your thing, but you could have a 'number of times/date of most recent backup' entry obvious in your token UI, and hope people notice abnormal ones.

Protecting from a Chris Tarnovsky[1] level attacker who is probing your silicon is probably beyond the scope of a cheap consumer unit.

The best way I (IANACryptographer) can immediately think of is that your hardware dongle generates an very large internal (never leaves the device) pgp keypair. It can be allowed to back up your internal password database only when encrypted by that key, so it is literally useless except on that single physical device. You could then enroll the pubkeys of your other devices as backups onto it, and the backups would then be multisigned where any one of the associated keys has the ability to decrypt.

The password blob can then be stored jsut about anywhere, but is only decryptable and useable when embedded into the hardware device.

[1] https://en.wikipedia.org/wiki/Christopher_Tarnovsky

http://finalkey.net/ looks like a step in teh right direction, although I'd prefer to see something a bit more compact, and ideally with an independent user interface.

Something like a smartcard, with an eInk display and membrane keypad, that lets you select a credential and then provide it to the application via keyboard injection, or where possible over using challenge-response over the existing smartcard interface so the secret never leaves the card.

There was a hardware bitcoin wallet not that long ago that was further down this road, I think maybe https://www.bitcointrezor.com/ ?

The biggest problems I can see for usability are:

* what can you do when you don't have it with you? - One answer would be some printable one-time tokens such as the fallback that google auth uses, that you can carry separately.

* Can it be backed up? In theory, the keys are in there permanently, and cannot be accessed by design. Having some Super Mega Master Password that allows a full copy to be made onto a second device that can be kept elsewhere might be sufficient.

* How to handle situations where you can't use USB/NFC for it to communicate. It would need a display to give you a code/your password to enter or something.

A smaller issue would be if you're planning on fully interoperating by generating and storing individual site/system credentials on there, it would have to handle the idiocies of various systems that impose password restrictions like special chars, numbers, maximum length, etc. If it's autotyping as a fake keyboard, would also need to deal with the 'retype your password' field somehow.

All in all, I think it's totally doable, but I'm not sure I'd trust a kickstarter-like project to get the details right, given the general (maybe just perceived) level competence of kickstarted projects. Crypto Is Hard. You can't really start having a 'stretch goal $10M - hire a real cryptographer to check we didn't twiddle our nonces' or something.

A decent and well-reviewed thing like this is probably somethign I'd buy though. I've just got a Yubikey to play around with, and need to start setting that up for SSH and other keys to my more important accounts.

> Something like a smartcard, with an eInk display and membrane keypad, that lets you select a credential and then provide it to the application via keyboard injection, or where possible over using challenge-response over the existing smartcard interface so the secret never leaves the card.

You might be interested in this:

https://hackaday.io/project/86-mooltipass

Interesting. I had seen that a while back I think, but totally forgot when writing my comment just now. It's not quite 100% what I was thinking, but it's closer than anything else.

U2f (Universal 2nd Factor) is a standard to have a 2nd factor authentication usb device that uses a different secret for each website/resource. The only problem is that a version 2.0 is being discussed and you can't be sure that today's hardware will work with it.

Reply on news.ycombinator.com