LastPass password vaults crackable for $100, alleges 1Password | Hacker News Reader

LastPass password vaults crackable for $100, alleges 1Password

appleinsider.com

55 pointsnonoesp27 comments

Open articleView on HN

Strange that the article doesn’t specify the $100 for what… I assume computing power.

Headline reads as someone is offering as a service. Anyone else read it like that?

Yes, first thing I thought.

Often the South Park episode about how Ads are disguising themselves as news. This is one of those times.

Shrewd business decision of course, but spammy and annoying to hear from a spokesperson's mouth.

I agree about the way the headline is written, but the article links to 1password's blog post (linked here a few days ago) that claims "the cost of cracking passwords hashed with 100,000 rounds of PBKDF2-H256" would be less than $100 USD for 10 Billion guesses.

Can anyone explain why all the emphasis on hashing algorithms? Can't the attacker just treat the encrypted vault like a black box and brute force passwords against it? Or is there some additional key material that needs to be guessed along with the password?

For example, if the master password is one of the 100k most common passwords, can the attacker loop through those passwords and attempt to open the vault with each? So there would only be 100k iterations required? Or does each check need its own set of iterations?

> Or does each check need its own set of iterations?

This is exactly what a password-key derivation function is. Each check is an independent process involving the unique salt stored in cleartext. Normally (OWASP recommendations) each password check is about 310,000 iterations of SHA256, or a more complex construction like Argon2.

The problem here is that LastPass had 5000 iterations of SHA256 for a lot of accounts, and some accounts mysteriously have even lower iteration counts.

Even if someone uses "123456" or "Password1," the salt will prevent the hashes from being identical. This means each vault has to be individually brute forced instead of having one master rainbow table. These key stretching operations can only add so much security. Obvious passwords fall first.

Could LastPass be an intentional backdoor from some Government or entity?

Perhaps, but barring concrete evidence it's safer to assume that it was bad practice rather than a malicious endeavor.

"Never attribute to malice that which is adequately explained by stupidity."

I assume it’s probably a trade off the consciously made for, in their opinion, a better end user experience experience.

Why would they claim breach and source code stolen instead of simply and silently hanging over vaults then?

Because they were never intending to be breached, it ruined the plan. The less-than-12 characters vulnerability is a joke

Can anyone recommend some “offline only” password generation tools? I don’t see why passwords need be stored on a server at all. Something with mobile support would be ideal

If you have more then one device, how are you going to generate the same password for the same site that's different from other people, but same for you?

(There are some existing ideas, but they often rely on the domain/url staying the same and that's often not the case in practice)

Keepass. You can still have sync between computers/phones using Dropbox while not having any unencrypted data in the cloud.

syncthing (or private git repo on trusted server) + pass/gopass/prs (with gpg key on Yubikey or similar hardware CCID/OpenPGP hardware)

It's not for everyone, but it's trivial to conceptualize ALL of it - you decrypt/encrypt plain text files in a dir, and something else syncs them. Your "manager" then becomes a tool with a nice CLI that just does `gpg -e`/`gpg -d` under the covers.

(I'd really like to see a tool that can take a publicly-shareable config file (email, name, country, origin date, keysize, seed) + a secret BIP39 phrase and spit out a GPG secret key, or better, just provision a new Yubikey from the phrase. Then my cold storage could just be my BIP39 phrase, rather than being my BIP39 phrase and an encrypted copy of my GPG key backup.)

pass/gopass/passage and KeePassXC can be offline-only, but usually you use some sort of tool to sync/backup the password store.

I use gopass with keys stored on yubikeys, which I think is secure enough. For syncing I use git, but since decoding the synced archive requires a key that is impossible to extract from my hardware keys I'm not that worried about leaks from the syncing.

+1 for pass and KeepassXC

In my opinion, Enpass has the best balance of privacy, open-source, offline-first, etc. It's essentially a proprietary UI over a sqlite/SQLCipher database (fully open source CLI available: https://github.com/hazcod/enpass-cli).

It can - but needn't - be sync'd any number of ways (iCloud, Dropbox, Google Drive, OneDrive, WebDAV), if that's what you like. Because it has WebDAV sync support, you can use it with ownCloud or NextCloud without much fuss, and not have to trust a third party at all.

I second Enpass. There is no online server involved. Syncing can be done with proprietary cloud solutions, Wi-Fi, or just manually using files.

But what I love best is their payment plans: the have the rare option for lifetime plans.

On my desktop I have a python script that selects N random words from the list I obtained from the eff website (link below).

Something to note is that the regular "random" standard library module in python is not intended for password generation or cryptographic purposes. Modern python has a module called "secrets" that provides secure random functions using randomness from the OS's CSPRNG.

If I need something like a binary key I just use /dev/urandom directly. You can pipe urandom through something like "tr" to remove non-printable bytes, or remove everything that's not in a set that you provide such as "a-zA-Z0-9!@#$%^&*()".

On Android I use the "pass" app, but I generate the passwords on my desktop and then share them with the phone after encrypting them with the phone's GPG key.

(wordlists) https://www.eff.org/dice

This blog post is the biggest load of shit I have read in a while, it jumps all over the place and does not deliver the message that it is trying to do. Instead it demonstrates arrogance by the author.

The difference between being breached and not being breached is huge and this authors mindset about 1passwords security would change a lot if he was in Lastpass shoes.

Goldberg's answer "The 1Password Secret Key may not be the most user-friendly aspect of our human-centered design..." is unfortunately true.

We experienced a lack of understanding on the user side that this secret key needs to be printed and stored safely. It feels like a huge barrier for the adoption of 1Password for non-IT affine people.

This and other challenges led us to develop heylogin which does not require a master password and has no secret key that needs to be printed. Instead we generate cryptographic keys using the user's smartphone. For providing your desktop browser temporary access to passwords you simply confirm on your smartphone. This feels similar to modern SSO solutions but is technically a password manager.

what's the recovery process when a person's smartphone is lost/stolen/broken?

How does a confirm push a key or password to a browser?

In our experience, a user with one phone doesn't really need this key. You'll always be able to log from that phone into that phone's vault with just the password.

It's only if you're adding another device or logging in online, or replacing a lost first device with no backup, that you need the 2nd piece of key material.

Secret keys are backed up in order to recover the data in the event of device loss, and master passwords are used to prevent data access by an attacker with disk access, including access to device backups in the cloud. Am I misunderstanding, or are you just accepting that the data gets lost or breached in those situations?

Reply on news.ycombinator.com