Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LastPass Security Notice

blog.lastpass.com

Post reply on HN
Print view View original

181–190 of 311 posts

Re: LastPass Security Notice

#181

Post by flycaliguy »

tbabb wrote: post #166
pdabbadabba wrote: post #22

Earlier quoted context omitted.

But this depends on the alternative. If, instead of using a password manager, uses only one (or even two or three) passwords across all the websites they frequent, then you are still, in effect, trusting numerous third parties to keep your password safe in the cloud--if any one of these sites is compromised, then your password for all (or half, or 1/3rd, etc.) is compromised along with it. I agree with you that an of…

My compromise has been to come up with a password permutation scheme-- I have a long, secure, high-entropy password which I can modify/salt in a way that's predictable (to me) across sites, such that each site's credentials are unique. Obviously this works across all devices, because the scheme is in my head, and it's simple enough to remember. I don't use any password manager, because like OP, that seems like too mu…

Would access to two of your passwords make the rest an easy target? that would be my fear with a system like that.

Re: LastPass Security Notice

#183

Post by PuffinBlue »

jjarmoc wrote: post #12

While LastPass seems to be responding well, I find their entire service exceeds my tolerance for risk. If you don't use a password manager, you've got 99 problems, but a centralized store of your credentials for everything that's a huge target by virtue of having thousands of similarly centralized users ain't one. Using a password manager (good idea) and then storing all your passwords on a 3rd party service of which…

You understand that all the passwords/data are encrypted client side and only the encrypted blob is stored in the cloud?

This is exactly what users of Keepass et al espouse when they talk of having their 'locally encrypted database' and syncing it over dropbox etc.

You, at least, are identifying the benefit of physical security, but if we are to place any trust at all in encryption then we must accept such a scheme (local encryption, cloud sync) as being robust, if correctly implemented.

Under this scheme, obtaining the encrypted blob (which hasn't happened in this case) would still not be a cause for alarm, if we are to trust the strength of the encryption scheme.

There comes a point that you must trust 'something'. That choice for me is in encryption.

Re: LastPass Security Notice

#184

Post by alexnewman »

I'm now too paranoid for lastpass ever again.

Sandstorm made setting up a private gitlab about a 5 second thing. I'll just checkin gpg encrypted textfiles once more.

There's a bunch of shell scripts called pass http://git.zx2c4.com/password-store/ which know about gpg, git and this format of text files. There's browser and android plugin as well. Amusingly it has basic import/export from every other password manager. I exported from lastpass and now all I have to do is switch to a new gpg key and buy all new hardware

Re: LastPass Security Notice

#185

Post by socceroos »

PuffinBlue wrote: post #183
jjarmoc wrote: post #12

While LastPass seems to be responding well, I find their entire service exceeds my tolerance for risk. If you don't use a password manager, you've got 99 problems, but a centralized store of your credentials for everything that's a huge target by virtue of having thousands of similarly centralized users ain't one. Using a password manager (good idea) and then storing all your passwords on a 3rd party service of which…

You understand that all the passwords/data are encrypted client side and only the encrypted blob is stored in the cloud? This is exactly what users of Keepass et al espouse when they talk of having their 'locally encrypted database' and syncing it over dropbox etc. You, at least, are identifying the benefit of physical security, but if we are to place any trust at all in encryption then we must accept such a scheme (…

ROT13 fan?

Re: LastPass Security Notice

#187

Post by dragontamer »

StavrosK wrote: post #151
dragontamer wrote: post #134

Earlier quoted context omitted.

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.

Re: LastPass Security Notice

#188

Post by PuffinBlue »

walterbell wrote: post #61
llimllib wrote: post #54

Earlier quoted context omitted.

> STRIP supports mobile-desktop synchronization over local wifi or remote cloud (Dropbox & Gdrive). Right, but the threat model here is exactly the same! Except you're trusting Dropbox and Google instead of LastPass.

Or you can use local WiFi -- now you have a choice. If you do choose a cloud service, note that the database file is encrypted by STRIP, https://www.zetetic.net/blog/2014/09/10/how-strip-syncs-with... "When initialized with a passphrase SQLCipher derives the key data using PBKDF2 (e.g. OpenSSL’s PKCS5_PBKDF2_HMAC_SHA1 on some platforms.) Each database is initialized with a unique random salt in the first 16 bytes of…

The LastPass database is encrypted client side too. Only the encrypted blob is synced to the cloud. Are people under the impression the passwords are stored up in the cloud in a for accessible to LastPass or otherwise unencrypted?

https://lastpass.com/whylastpass_technology.php

Re: LastPass Security Notice

#189

Post by dragontamer »

ecdavis wrote: post #157
dragontamer wrote: post #134

Earlier quoted context omitted.

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.

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!')

Re: LastPass Security Notice

#190

Post by StavrosK »

dragontamer wrote: post #187
StavrosK wrote: post #151

Earlier quoted context omitted.

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.
Post reply on HN