Beep boop - this is a robot. A new show has been posted to TWiT…
What are your thoughts about today’s show? We’d love to hear from you!
Just got Steve’s info, QNAP NAS generally are set up to email the administrator when a new update is available.
I get notices from my work and home devices every month, when the patches arrive. On the other hand, I use them as a NAS for data storage and backup (one of the different backups) and they are not on the internet.
Is LastPass really “Zero-knowledge”?
You can reset a forgotten master password by simply requesting an email link, to a web form, be sent from the “Forgot Password” option on the LastPass Login page. The code behind that page has a means to decrypt your vault, and re-encrypt your vault with the substitute password you’ve been prompted to enter twice, all without any need to supply a master password.
First some background. The contents of your vault is not encrypted with your master password. Shocking I know, but true. It is encrypted with some random 256bit value (the AES key). This key is what your master password protects. This means you can change your master password without having to completely rewrite the entire password vault.
Now for the trick, this also means some other random value can also encrypt the vault key. Such a thing is called a Recovery One Time Password. The docs say:
https://support.lastpass.com/help/recover-your-lost-master-password-lp020010
So one presumes the process is that you use the one time code to decrypt the vault password, then you choose a new master password, which is used to encrypt the vault password.
It’s unclear, without attempting the process, to see what if any protections are in place to prevent just anyone with access to your device from resetting your password in this way.
2 Likes
Or to put it another way:
Parts of your LastPass Vault are encrypted through the AES-256 algorithm, with the protecting KEY, generated ONCE, from your chosen mater password, email address, and possibly some other salts, that may not be held in plain text in your vaults meta data, the resulting KEY is hashed by one to a user specified number of PBKDF2 SHA-256 rounds of obfuscation. Copies of this hashed KEY are then held on an unknown number of devices, and by an unspecified number of 2nd and 3rd parties, and accessible without having to re-enter your master password, to in future be able to decrypt the encrypted elements of your cloud backed up, globally accessible vault.
Is this really zero-knowledge?
You have misunderstood how it works… but in any case, it’s potentially zero knowledge, yes. It depends on which features of LastPass you use. If you use the “give access to my spouse in case of my incapacitation” feature, then they have to do things to limit your security in order to implement that specific feature. (I will admit I have not dug into how they do that feature specifically.)
But in general, if you only use LastPass for storing data in your vault, the secrets that protect the vault are only accessed on the devices that you use. The server does not have access to the master key, nor the AES key, nor any of your data, until you use the vault. If you use the LastPass vault on the LastPass site, then the page you see has knowledge of your master password while you remain logged in. That still doesn’t mean the server has any need of your master password.
Set up a 2nd means of authentication on an account, be it a printed authenticator grid, a Google Auth pairing, recovery phone number, … logout, Then from a web browser make like you’ve forgotten your master password, receive an email link, use JUST one of the 2nd means of authentication and reset your master password in the browser, which would only be possible if an persistent copy(copies) of your PRIVATE key exist, and can be retrieved from somewhere by entering either a one time password, authenticator code, data grid value, … to authorise their use to decrypt your existing vault, no master password required, and re-encrypt it with a new KEY generated from the entered replacement password, the email address the reset link was mailed to, and stored number of PBKDF2 rounds.
Keeping a plain text copy of your email address ( Master password SALT) and number of PBKDF2 rounds could also be regarded as violating the zero knowledge claim, as both could be useful in a dictionary attack, on the encrypted elements of a vault, eg.
// Pseudo, single threaded, Java’ish, without any exception logic to attempt a dictionary attack on an PBKDF2WithHmacSHA1 encrypted string, where the KEY LENGTH, SALT and HASH ROUNS COUNT are KNOWN !!!.
import javax.crypto.Cipher;
import java.security.spec.KeySpec;
import javax.crypto.spec.PBEKeySpec;
import javax.crypto.SecretKey;
import javax.crypto.spec.SecretKeySpec;
import javax.crypto.SecretKeyFactory;
import java.security.AlgorithmParameters;
import javax.crypto.spec.IvParameterSpec;
import java.util.ArrayList;
import java.util.Arrays;
import java.util.List;
public class PseudoDictAttact() {
List commonPasswordsList = new ArrayList();
SecretKeyFactory keyFac;
Cipher dcipher;
SecretKey key, tmpKey;
KeySpec keySpec;
byte iv;
// From vaults content
byte emailSalt = new String(“someBody@someDomain.Something”);
String siteLoginURL “https://www.someSiteOrOther.whatever/login?userName=someBody”;
int hashRounds = 5;
int keyLength = 256:
String vaultEncryptedString = “e8KlSHVqbTg3NDsrSGlVSzgjSzjCozprakpIaElFS01kSmU4M2pqwqUK”;
PseudoDictAttact() {
loadCommonPasswords();
keyFac = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
}
private static void loadCommonPasswords() {
// Add the most common 10,000 passwords, by some means
commonPasswordsList.add(“qwerty123”);
commonPasswordsList.add(“1234qwerty!”);
commonPasswordsList.add(“myPassword!”);
commonPasswordsList.add(“Passw0rd!”);
commonPasswordsList.add(“mySecret!”);
commonPasswordsList.add(“guest1234!”);
// …
commonPasswordsList.add(“theWorld’sFullOf!!!”);
}
public String decrypt(String base64EncryptedData) {
dcipher.init(Cipher.DECRYPT_MODE, key, new IvParameterSpec(iv));
byte[] decryptedData = new sun.misc.BASE64Decoder().decodeBuffer(base64EncryptedData);
byte[] utf8 = dcipher.doFinal(decryptedData);
return new String(utf8, "UTF8");
}
private String dictionaryAttack () {
String possiblyCrackedString;
i=0;
while ( i < commonPasswordsList.size() ) {
keySpec = new PBEKeySpec(commonPasswordsList.get(i).toCharArray(), emailSalt, hashRounds, keyLength);
tmpKey = factory.generateSecret(keySpec);
key = new SecretKeySpec(tmp.getEncoded(), "AES");
dcipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
possiblyDecryptedString = decrypt(vaultEncryptedString);
//If the decrypted string looks like something
if(possiblyDecryptedString.matches("(.*)123(.*)") || possiblyDecryptedString.matches("qwerty.*") || commonPasswordsList.contains(possiblyDecryptedString) || ... ) {
Break;
}
possiblyDecryptedString = "";
i++;
}
return possiblyDecryptedString;
}
}
public static void main(String args) {
PseudoDictAttact pseudoDictAttact = new PseudoDictAttact();
String possiblyCrackedString = pseudoDictAttact.dictionaryAttack();
If( ! possiblyCrackedString.isEmpty() ) {
system.out.println("May have been: " + possiblyCrackedString);
system.out.println("Encrypted with master password: " + commonPasswordsList.get(i));
system.out.println("Shall I attempt to plug this it into the URL stored in plain text with the string [Y/N]? " + siteLoginURL);
…
}
}
NO! Just NO! Stop this bs. You don’t understand cryptography at all if you say s__t like that.
1 Like
If you look at any of standard libraries, the applicable API call, eg.
javax.crypto.spec.PBEKeySpec(), used by a few billion Android devices, and many a corporate Web App, to set up the hashing of a passphrase; the functions take 4 parameters:
passphrase - UNKNOWN (but dictionaries of common passwords exit)
salt - in LastPass’s case it is apparently the accounts email address
iteration count - an integer, in LastPass’s case was by default: 1 (2008), 500 (Jun 2012), 5,000, 100,100 (Feb 2018), 600,000 (Feb 2023), or a user modified entry, with the current value held against each account.
key length - 256
Of the parameters, the backups will offer 3, of the 4 necessary, variables, to make an attempted dictionary attack trivial, and if those with an iteration count of 1, 500, 5000 are targeted first, computationally cheap, and possibly more likely to have a master password that’s in one of the top n thousand passwords, as there vault and password hygiene is likely decades behind the curve.
Though i suspect there’s a bigger prize, a store of all account Keys. If the account recovery vault was backed up to the same globally accessible AWS buckets, located and opened, the contained keys would allow every copied LastPass vault to be decrypted, in one go, no guessing. Every username, password, url, Social security number, bank card number, secure note, …, of every customer, contained in the backups all instantly public, though likely for a price.
If the vault recovery operations are’t sufficient to convince you that copies of your hashed master password persist, try upping the iteration count on your vault to somewhere between 1 and 3 million, so it takes a couple of min’s to hash a password, with your email address. Set a new password on your vault, and twiddle your fingers / time how long its taken to hash your new master password. Logout and then log in to the website with your new master password, or say perform a vault security check. If the login operation take seconds, rather than mins you’ve noted, a copy of your hashed master password persists, and is being retrieved rather than hashed on you now entering your new master password, or alternatively a one time password, or one of the other authentication methods.
PBKDF2 and other key stretching algorithms are not so much security as they are delay. The iteration count is only relevant if you’re assuming the attacker is trying to brute force a weak password. The solution this problem is to not have a weak password. A password salt is also not security so much as a preventative measure against rainbow tables. If a sites password database is exposed, and the algorithm is known (as most are) and if they don’t use salting on the passwords, then two identical passwords will hash identically and thus you can use a lookup table of pre-hashed passwords to match against, which allows an “instant” password crack. Since this issue has been known for decades, all modern password hashing designs include a salt. Incidentally, the salt is not meant to be a secret, and is needed to verify the password later, so this is why it’s usually stored with the hashed password.
LastPass definitely had bad opsec, but they were also definitely directly targeted, and that is why they suffered the breaches they did. No end user that has a secure password (ideally a passphrase) will ever have to worry about the breach of their encrypted data, but it is true that there was unencrypted data in the vault that may prove mildly damaging to some users (the URLs of the site they had vault entries for.)
So to repeat what I said before. You don’t seem to understand how modern cryptography is done, you don’t seem to understand why the approach that LastPass used is considered zero knowledge, and you seem to want to argue from your point of poor understanding that there are other risks which don’t exist. LastPass is suffering plenty, but they don’t need people making false or invalid claims as you’re doing, so please just stop.
Just got through the episode, wanted to add a little anecdotal knowledge WRT weekly reboots. The university I went to essentially made weekly reboots a ritual. Everything went down on Tuesdays at 3 a.m. for weekly reboots.
I haven’t seen many other places do this. Even most of the *NIX admins I talk to tend to leave things up and running until reboots are necessary. High uptimes used to be a badge of honor, but I’m glad “just reboot it already” is becoming a more common mantra.
Personally, I just run SOHO servers so I don’t have to worry about any kind of a proper schedule. ‘unattended-upgrades’ reboots overnight as required, and all’s run well for years!