Moz in Oz • December 26, 2022 8:35 PM

Writing down the master password is all but essential if there’s anything important in your password database. The lawyer who did my wills (living and dead) was adamant about that. There are fun crypto system to let you distribute bits of a password around so that it’s harder for people who have other things to think about to make it work at all. Meanwhile you’re in a coma and the bailiffs are selling your house, “comes with a ready-made family for the lucky buyer”. Write the bloody thing down, put it in a safe place. My lawyer has half the password plus a list of people who each have a copy of the other half. And they have a copy of the file from ~2 years ago, and know how to get the latest one off my website(s), and that my work has a copy of it.

Security is always a balance, and I’ve been around long enough to have seen a few too many “Bob died so his website is gone forever”, not to mention seen families wandering lost in technology wondering whether Bob really had investments at all, or were they concealing a gambling problem (trick question, it was both: they invested in cryptocurrency). If no-one knows where you invested they can’t use your death to access those funds.

Last August, LastPass reported a security breach, saying that no customer information—or passwords—were compromised. Turns out the full story is worse: //

To date, we have determined that once the cloud storage access key and dual storage container decryption keys were obtained, the threat actor copied information from backup that contained basic customer account information and related metadata including company names, end-user names, billing addresses, email addresses, telephone numbers, and the IP addresses from which customers were accessing the LastPass service.

The threat actor was also able to copy a backup of customer vault data from the encrypted storage container which is stored in a proprietary binary format that contains both unencrypted data, such as website URLs, as well as fully-encrypted sensitive fields such as website usernames and passwords, secure notes, and form-filled data.

That’s bad. It’s not an epic disaster, though.

These encrypted fields remain secured with 256-bit AES encryption and can only be decrypted with a unique encryption key derived from each user’s master password using our Zero Knowledge architecture. As a reminder, the master password is never known to LastPass and is not stored or maintained by LastPass. //

John Thurston • December 26, 2022 1:31 PM

“I think the question of why everything in the credentials store was not encrypted is interesting. What possible advantage is there of not just encrypting the whole thing under your master password.”

Because this is how Lastpass is able to offer to supply uid:pwd values when you have not unlocked your vault. If this information was kept encrypted, then the browser extensions would not know when to prompt you to unlock to supply the creds.

I’ve never liked this ‘feature’, but there’s nothing I can do about it. //

Wladimir Paöant • December 27, 2022 6:56 AM

I would have been less problematic had LastPass not messed up. They:

1. Failed to upgrade many accounts from 5,000 to 100,100 iterations.
2. Didn’t keep up with cracking hardware improvements (100k iterations are really on the lower end today).
3. Didn’t bother existing their new password complexity rules for existing accounts.
4. Didn’t bother encrypting URLs despite being warned about it continuously, allowing attackers to determine which accounts are worth the effort to decrypt.

Their statement is misleading, they downplay the issues. I’ve summed it up on my blog here: https://palant.info/2022/12/26/whats-in-a-pr-statement-lastpass-breach-explained/ //

Modern Authentication is an umbrella term originally defined by Microsoft, but many other companies also use it to describe a set of the following:

• Authentication methods (authentication = how something/somebody logs in to a system)
• Authorization methods (authorization = mechanisms that make sure you do not have full access to something by default)
• Conditional access policies (policies which define the conditions under which certain additional steps have to be taken in order to log into a system)

Authorization and authentication methods are standardized in the digital world. The industry standard for authorization is OAuth2. For authentication there is no industry standard, but the standard which is most widely used is OpenID Connect. Although they serve different purposes, these standards are very much related from a technology standpoint. The OpenID Connect protocol suite extends the OAuth protocol and they are based on the same technologies. OAuth was never designed to authenticate users or persons, but only services. That is why OpenID Connect was created.

How would Modern Authentication look like in our airport analogy? With Modern Authentication, the procedure seems quite familiar: You fly abroad, leave the plane and go to the security officer at the border control. The officer asks to see your passport on which he can find all the important information needed to identify who you are and where you are from. This information is protected by anti-forgery mechanisms. In the digital word, the passport is what we call an ID token. This token contains important information: who you are, who created the token, how long it is valid, etc.
Where Does Multi-Factor Authentication (MFA) Fit Into the Mold?

Two-Factor Authentication (2FA) and Multi-Factor Authentication (MFA) are a part of the authentication process. The process is as follows: You as a user connect to your identity provider who needs to validate that it is really you trying to connect. Depending on the conditional access policies which are defined by the administrator, your identity provider might ask you for further information. If he believes that just entering your credentials is not enough to authenticate you, for example when you are connecting from an unknown network, he may ask you for additional information, for instance a code which is sent to your mobile phone. Microsoft has implemented this in a very dynamic way. Their systems continuously learn and decide what is a secure system and what is not.

Hashcat is a popular password cracker and designed to break even the most complex passwords representation. To do this, it enables the cracking of a specific password in multiple ways, combined with versatility and speed.

Password representations are primarily associated with hash keys, such as MD5, SHA, WHIRLPOOL, RipeMD, NTMLv1, NTMLv2 and so on. They are also defined as a one-way function — this is a mathematical operation that is easy to perform, but very difficult to reverse engineer.

Hashcat turns readable data into a garbled state (this is a random string of fixed-length size). Hashes do not allow someone to decrypt data with a specific key, as standard encryption protocols allow. Hashcat uses precomputed dictionaries, rainbow tables and even brute-force approaches to find an effective and efficient way to crack passwords. 

This article provides an introductory tutorial for cracking passwords, using the Hashcat software package.

Thought experiment story of someone who lost everything in a house fire, and now can’t log into anything:

But to get into my cloud, I need my password and 2FA. And even if I could convince the cloud provider to bypass that and let me in, the backup is secured with a password which is stored in—you guessed it—my Password Manager.

I am in cyclic dependency hell. To get my passwords, I need my 2FA. To get my 2FA, I need my passwords.

It’s a one-in-a-million story, and one that’s hard to take into account in system design.

This is where we reach the limits of the “Code Is Law” movement.

In the boring analogue world—I am pretty sure that I’d be able to convince a human that I am who I say I am. And, thus, get access to my accounts. I may have to go to court to force a company to give me access back, but it is possible.

But when things are secured by an unassailable algorithm—I am out of luck. No amount of pleading will let me without the correct credentials. The company which provides my password manager simply doesn’t have access to my passwords. There is no-one to convince. Code is law.

Of course, if I can wangle my way past security, an evil-doer could also do so.

So which is the bigger risk?

• An impersonator who convinces a service provider that they are me?
• A malicious insider who works for a service provider?

• Me permanently losing access to all of my identifiers?

  I don’t know the answer to that.

Those risks are in the order of most common to least common, but that doesn’t necessarily mean that they are in risk order. They probably are, but then we’re left with no good way to handle someone who has lost all their digital credentials—computer, phone, backup, hardware token, wallet with ID cards—in a catastrophic house fire.

I want to remind readers that this isn’t a true story. It didn’t actually happen. It’s a thought experiment. //

Kent Brockman • June 28, 2022 11:04 AM

Any plan should take into account the possibility of memory loss (permanent or otherwise) due to shock or physical injury from an incident (car crash,fire, etc.,etc.) which would render moot a passphrase, plan, etc. unless written down and distributed to others (trusted implicitly, of course). This is to my mind at least, possibly the largest risk to even a well thought out scheme.

Security Sam • June 28, 2022 11:25 AM

For safety the security abhors
With a mutually exclusive rule
Just like the set of double doors
Located in every bank vestibule.

Plesk Password Strength Policy

Levels of strength

Time to crack

Plesk uses a 3rd-party open-source solution to identify the password strength. The solution could  be checked at:
https://zxcvbn-ts.github.io/zxcvbn/demo/

How Apple, Google, and Microsoft will kill passwords and phishing in one stroke

You've heard for years that easier, more secure logins are imminent. That day is here.

How Secure Is My Password?

most easy password

It would take a computer about
4 hundred billion years

Travel Mode removes vaults from your computers and mobile devices, except those you mark as safe for travel.

Travel Mode is included with every 1Password subscription. If you’re stopped for inspection while traveling, the only vaults on your devices will be the ones you’ve marked as safe for travel.

Right before you travel, turn on Travel Mode:

1. Click your name in the top right and choose My Profile.
2. Turn on Travel Mode.
3. On the devices you’re traveling with, open and unlock 1Password. Vaults that haven’t been marked as safe for travel will be removed from the app.

When you’re done traveling, return to My Profile and click to turn off Travel Mode.

Whenever you turn Travel Mode on or off, you’ll need to open 1Password on your devices while connected to the internet for the change to take effect.

After many high-profile and widespread major data breaches – which have compromised millions of people – many people have come to understand more about password security and the fact that a simple password can’t keep their online profiles safe. That has led to the rise in the popularity of two-factor authentication, an additional layer of security that can keep online accounts secure.

the security of the Chrome saved passwords depends totally on the user:

• Use a very strong Windows account password. Keep in mind, there are utilities which can decipher Windows passwords. If someone gets your Windows account password then they have access to your saved browser passwords.
• Protect yourself from malware. If utilities are able to easily access your saved passwords, why can’t malware?
• Save your passwords in a password management system such as KeePass. Of course, you loose the convenience of having the browser auto-fill your passwords.
• Use a 3rd party utility which integrates with Chrome and uses a master password to manage your passwords.

Q:

As far as I know, current versions of Mozilla Firefox store the saved passwords (encrypted with 3DES) to the logins.json file meanwhile the keys are stored in key4.db (or key3.db in older versions).

If one hasn't set up a Master Key for the passwords, the key database file can then be accessed. In the database, I've encountered an entry that does indeed look like the keys.

So, why possibly are there two 3DES keys in the database? Are they really encryption keys? How can I use them to decrypt the logins.json data? Which keying option is being used?

A:

In the data structure, item1 is the global salt, and item2 contains (in DER encoding) the entry salt and the encrypted key. This key is used to encrypt the rest of the data (per username and password).

The encryption of the master key is done with 3DES-CBC, with a key (and IV) derived from the master password, a global salt and a "per entry" salt. By default, the master password is the empty string. The password's entropy is bounded to 160 bits by sha1, which is further bounded to 112 bits by 3DES. The password is not hardened using multiple iterations of an hash.

The encryption of items (usernames and passwords) is done using 3DES-CBC, with an IV included in the metadata of each item. How IV is generated cannot be guessed from this source of the algorithm.

Unless the IVs are poorly generated, the small amount of data encrypted means that the best attack on 3DES is brute-forcing the master key or the user's password. The upper bound of 112 bits means that is this algorithm is considered weak by today standards: a big organization with huge resources might be able to brute-force the key in a few decades. Quantum computers might break them faster.

In practice, this means that a good, long passphrase must be used as the master password.

The RedLine information-stealing malware targets popular web browsers such as Chrome, Edge, and Opera, demonstrating why storing your passwords in browsers is a bad idea.

This malware is a commodity information-stealer that can be purchased for roughly $200 on cyber-crime forums and be deployed without requiring much knowledge or effort. //

While browser password stores are encrypted, such as those used by Chromium-based browsers, information-stealing malware can programatically decrypt the store as long as they are logged in as the same user. As RedLine runs as the user who was infected, it will be able to extract the passwords from their browser profile.

Bill • November 16, 2021 8:34 AM

The NIST has already advised on passwords, and issued guidelines a couple of years ago — recommending LESS COMPLEX passwords (no rules) in favor of longer passwords.
They cite research indicating that complex passwords are not harder to crack, and are much harder to remember (which is why people write them down, or now use password managers). Longer passwords, on the other hand, can be easy to remember as phrases or strings of words, etc. Longer passwords are harder to crack. //

William Entriken • November 16, 2021 9:27 AM

NIST has published guidelines on what types of passwords should be accepted for login systems. We should promote and share solutions to the problem.

https://pages.nist.gov/800-63-3/sp800-63b.html

Specifically the relevant recommendation here is: Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. //

Usability has a huge impact on how people interact with systems. If you purposely make the experiance different from site to site – users will take shortcuts including making weaker passwords. A common “password standard” would benefit everyone greatly and reduce risk over all.

For those who want to lock things down without going offline and moving to a bunker in New Zealand, the first step is to assess the following things:

• What in my digital life can give away critical information tied to my finances, privacy, and safety?
  • What can I do to minimize those risks?
  • How much risk reduction effort is proportional to the risks I face?
  • How much effort can I actually afford?

First, if you're not at home, you should always lock your device before you put it down, no exceptions. Your phone should be locked with the most secure method you're comfortable with—as long as it's not a 4-digit PIN, which isn't exactly useless but is definitely adjacent to uselessness. For better security, use a password or a passcode that's at least six characters long—and preferably longer. //

Second, set your device to require a password immediately after it’s been locked. //

Also, regularly back up your phone. //

[Don't install bad apps -- consider carefully where it comes from, what it does, if you really need it.] //

Consider turning off Wi-Fi when you’re away from home. Your device may otherwise be constantly polling for the network SSIDs in its history to reconnect automatically or to connect to anything that looks like a carrier’s Wi-Fi network. When this happens, your device gives away information about networks you’ve seen and might allow a hostile network access point to connect. Also, your phone's Wi-Fi MAC address could be used to fingerprint your device and track it. //

The same goes for Bluetooth. If your device has Bluetooth turned on, it’s broadcasting information that could identify it—and you. //

Along those same lines, name your device anything other than [Your Name]’s iPhone. Your phone's network name is broadcast all around you, and it's like holding up a beacon saying "Hello, my name is..." //

[Malware protection on your PC] Even allowing Windows Defender to run in the background provides a significant bump in protection over nothing, and disabling it without a very good reason is a very bad idea. //

[Keep your OS & software up to date -- install updates as soon as they are available ]

[Turn on Windows Firewall when in public]

In the event that your physical device is compromised, you can minimize damage by caring for your actual data. To prevent all types of data loss, back up your data—in encrypted form and offline (either locally or in the cloud) so that ransomware doesn’t get the backups, too. Keep multiple backups just in case, because if your latest backup contains the compromised or encrypted files, it's useless.

And don't just back up your data, use full-disk encryption. Period. It's a one-time setting to activate and there are no excuses for not using it. Full-disk encryption transparently encrypts your hard drive so data can’t be read off of it without your credentials. //

Wi-Fi access points and routers that support firmware or software updates add another layer to the security of your devices while web browsing. If you have an older Wi-Fi access point that you can’t update, toss it. //

And, finally, use a password manager. An easy-to-guess password renders all other security efforts moot. Whether it’s a password built into your web browser of choice or a standalone program, use one. Chrome, Firefox, and Safari all have reasonably secure password managers, and you can replicate passwords for web accounts across devices. If you don't like the idea of a password manager because you're one of those folks who just uses letmein123! as your password everywhere, you need to decide if the convenience is worth the price you'll eventually pay when you're compromised. (Spoiler alert: it's not.)

My company policy states I must put all passwords in a password safe shared with management. Is this secure?

As the title says, my company has a policy that all passwords to e.g. our workstations and server logins must be stored in an online safe. I won't say which one but there are some out there you can look at promising the end of password pain. These passwords are then shared with the company's management - I don't know how that bit works, but they can read the passwords too. //

None of the reasons you've given are valid reasons for escrowing your password. There's only a couple valid reasons for escrowing any sort of "authenticator" information. A couple others have touched on these, but I'll try to clarify a bit.

1. Encryption Keys: It makes absolute sense for the organization to have access to escrow copies of your encryption keys. After all, the data you're encrypting (provided you're only using your company's encryption for work purposes, of course) is their data in the end anyway. So, they need to retain access to that data in the event you lose your key or you are separated from the company. However, the encryption key should not be the same key you use for digital signatures. Also, they should not have actual access to your authenticator - the passcode you use for the key. Instead, they should have their own escrow key that works with their authenticator to decrypt your data.

2. Failsafe Accounts: It also makes sense that the organization should have backup copies of credentials necessary to access an Administrator-level account in the event the System Administrator's own account is locked out, or they depart the company. However, the credentials should not be for the System Administrator's own account. They should be for a local system account whose sole purpose is for emergency use. To that end, the account should also never be used for non-emergencies and its usage should be closely monitored and alerted. Traditionally, credentials for accounts like these are sealed in tamper-evident envelopes and stored in a secure, physical vault. It's conceivable that there may be digital equivalents, but I personally wouldn't trust those without a thorough review.

There's two big reasons why it's a bad idea for management to have your password. The first reason is potentially very bad for you, as it could end up causing otherwise unnecessary work for you if things go wrong. However, the second actually turns this around and makes it potentially worse for the company than it is for you if things go really wrong.

1. Potential For Abuse: The obvious one - managers now effectively have unrestricted access to the systems, regardless of whether they should, with the same privileges you have. Most simply this means that the managers may leverage this to do things on the system that they otherwise should not be doing. This also leaves the potential for them to bypass your position whenever they want to rush a particular change along without following standard procedure.

2. Loss of Non-Repudiation: Once someone else has your credentials - and, especially in a case like this where it can be proven they do - they can impersonate you on any systems where those credentials are valid. This makes it difficult to definitively prove that any actions taken by your account were actually taken by you. If a manager does decide to use your account, and ends up royally screwing up the system, it won't be very easy to use you as a scapegoat even though your account is in the logs. Worse for the company is, if you do something to royally screw up the system while your managers have your password, they'll have a harder time proving that it was actually you that did it.

TL;DR: There's no good reason I can think of for management to have any of your passwords. As for the reasons they've given:

1. "If you forget your password..." another System Administrator can reset it for you. Or, management can "break the glass" on the emergency account (see "Failsafe Accounts" above) and do it themselves.
2. "If you turn evil..." again you can be locked out by another System Administrator, or the emergency account. //

No, it is not a good idea. Thomas explained why it doesn't achieve its own goals, but it is worse than that.

Consider what happens when a rogue employee misbehaves causing damage to the company.

During the trial, you are subpoenaed to testify about logs showing that it was the employee who caused the damage, and are asked who else could log in as this employee. You truthfully answer that anyone with access to the safe including all of management could log in as that employee and your logging systems would be none the wiser.

Anything that blurs the distinction between actor and authenticating credentials seriously undermines the company's ability to use access logging to discourage misbehavior or recoup damages.

Managers often hand out passwords to subordinates when an IBAC system fails to explicitly handle delegation, but this is the reverse of that case, where the blurring affects the credentials of the much larger group of lower-level employees.

Appendix A of NIST 800-63B addresses this well. Avoiding password patterns is specifically why they recommend against arbitrary password complexity requirements and arbitrary password expiration times. Passwords should only be force expired on events. Timed expiration and complexity rules encourage patterns that make the password weaker. //

Levenshtein distance as a proxy for password strength is extremely limited, for the reasons that schroeder has outlined. And the user experience will probably be poor.

But the question is still academically interesting, and may be useful as a component for some use cases - so it still deserves a thorough answer. :D

Generally, the minimum Levenshtein distance between a previous password and a new one should be the same size as the minimum length of a randomly-generated password that would resist brute force (adjusted to the attacker's threat model). But it's important to note that even this minimum is often inadequate. //

Best case - the passwords are entirely randomly generated, both initially and later. In this case, Levenshtein distance isn't as relevant (or rather, measuring the Levenshtein distance between two randomly generated passwords is just a proxy for measuring the quality of their randomness). //

If we assume all worst cases (human-generated password, poor password-selection strategy, etc.), the answer should be clear: the amount of change in the password should itself be enough to withstand attack on its own - totally independent of the previous password (as if the first password was empty), and as if it was stored using a very fast hash like MD5. This is reduced to how fast we can reasonably expect a randomly generated password to be exhausted for a given threat model, and is covered well elsewhere (but can often hover around 13-15 random characters). //

In other words ... just like Shannon entropy, usefulness of Levenshtein distance as a measure of password strength is really only useful in cases where the passwords are already randomly generated. And if you're doing that, you already have the information necessary to keep them strong, without trying to measure the difference between two of them.

In even other words ... very low Levenshtein distances are an OK proxy for password change weakness, but high Levenshtein distances are a very poor proxy for password change strength. So my answer tries to find a balance between the two.

Even taking into account the physical separation of second-factors I mentioned earlier, and the reliance on your smartphone, it’s still a win-win for most people, most of the time. That’s becuase most people don’t have unique, long, complex, random passwords for every account and use a password manager to, well, manage them. That said, if you do, then there’s no real rush to dump your password access route to be honest.

To remain protected online, you should check whether your initial line of defense is secure. First, check your password to see if it’s compromised. There are a number of security programs that will let you do this. And make sure you’re using a well-crafted password.

We also recommend you limit the use of SMS as a 2FA method if you can. You can instead use app-based one-time codes, such as through Google Authenticator. In this case, the code is generated within the Google Authenticator app on your device itself, rather than being sent to you.

However, this approach can also be compromised by hackers using some sophisticated malware. A better alternative would be to use dedicated hardware devices such as YubiKey.

These are small USB (or near-field communication-enabled) devices that provide a streamlined way to enable 2FA across different services.

Such physical devices need to be plugged into or brought into close proximity of a login device as a part of 2FA, therefore mitigating the risks associated with visible one-time codes, such as codes sent by SMS.