72

You say you want the browser to suggest a recognizable (which I take to mean coherent) phrase. Have you thought about how a browser would implement that? The browser cannot keep a long list of such phrases, because for the list to be even remotely secure, it would have to be ridiculously large. If the browser tries to use some sort of AI to create a coherent ...


46

If we are talking about passwords generated by a password generator, the password: needs to be generally applicable to any site, which means it should generate a password that would comply with most password complexity rules (a-zA-Z0-9!@#$%^&*()) does not need to be memorable, since the password manager will remember it for you needs to be random enough ...


30

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 ...


26

You explicitly want to know if one can calculate a "safe" Levenshtein distance for a password. The answer is "maybe" but the answer would be irrelevant. whether in targeted attacks, a hacker could build up a dictionary for a single person using a list of passwords already found (e.g. from a compilation of breaches) Sure, this could ...


17

Recognizable phrases tend to have low entropy, so dictionary attacks against them would work the same way they work against recognizable passwords. But a very similar approach has been implemented in Diceware. Initially that was just a word list containg 6**5=7776 easily pronouncable words. Next to each was a five-digit number, and you would roll a dice 5 ...


10

I would like to question your assumptions. the sheer length (49 characters) should also make it impossible to crack, but because it's a recognizable phrase it's also much easier to remember. A long password does not make it impossible to crack. A long random password is hard to crack, but a long password from a short list is easy to crack as soon as the ...


9

Don't be “clever”. An obscure reference you come up with could be less obscure than you think. For example, your offered passphrase is a quote from JRR Tolkien's The Fellowship of the Ring and is therefore not strong enough (a persistent and well-informed attacker will crack that in days at the longest). Don't hide behind perceived obscurity; passphrases are ...


7

From a security perspective, this metric is meaningless. First, a password leak typically leads to a trivial attack in which the attackers will simply attack all accounts in the leak, looking for those who did not change their passwords at all. These are the low-hanging fruits and why should an attacker bother with your account that changed its password when ...


6

The other answers have mostly answered the question. However, there is one reason that is missing from all of them: Most websites set a very low limit on the password's length. Length restrictions of 12, 16, or 30 characters are common. In my experience, banks are particularly guilty of this, sometimes even limiting the password's length to 8 characters. The ...


6

A couple reasons come to mind, Locale For a non native english speaker, a long english string may look dissimilar to the shorter random assortment but now they have to find a way to enter or store this longer string that is just as confusing as the alternative Appearance of security To a non-tech savvy person, the assortment would appear more secure ...


4

As A. Hersean says, it's all about the threat model. One scenario not mentioned by him is remote access. If you want to set up your system so that you can RDP or ssh into it remotely, or want to share your files over the network (which, I think, is enabled by default when you connect to a network that you haved marked as private), your windows password is ...


4

As always, it depends on the threat model. If the threat is a coworker or a family member without the technical skills or the motivation to remove a drive and mount it elsewhere to read its content, a password on an computer without an encrypted drive is a good enough protection to the confidentiality of its data. If the threat is a malware (maybe targeted), ...


4

Levenshtein distance is the incorrect metric here. The correct cryptographic metric for the security of a password is the size of the output keyspace (that is, the image of our procedure - the set of possible outcomes). This size is upper bounded (but not necessarily equal to†) by the number of distinct operations you perform. Under Kerckhoffs's principle we ...


4

Password generators can already do this, yours is just not very good. Keepass has had a passphrase function for ages: Many other password generators have also supported passphrases for a long time now, it's not exactly a new idea. Apparently only your browser's developer didn't get the memo, probably because they expect that people who are knowledgeable ...


4

We currently believe that 128 bits of security should be sufficient for current and future needs. Much of this is due to physical constraints: using the theoretical minimum energy to store 2^128 bits of data would require more energy than is required to boil the world's oceans. If you're using a password manager, that means that a 20 character truly random ...


3

Information entropy only applies as a measure when the characters are chosen randomly and uniformly. Choosing the first letter of each word in the sentence is inherently non-random and non-uniform, so you cannot calculate the entropy of passwords generated by this scheme. Any estimation would be a gross simplification to the point of being misleading. Since ...


3

To answer your main question of why they suggest a mix of letters and numbers is because it's much easier to program a password generator that is great at spitting out random characters rather than complex word phrases that never repeat. Also the likelihood of another person using the random characters in the same sequence is almost impossible after a ...


2

Using a new password with a Levenshtein distance of 1 would probably not be too smart, as the cost of checking a good subset of that for each password wouldn't be too high, and may be successful enough to be worth checking (2 still wouldn't be too smart, but this is less practical to check for each password). Checking further than that with Levenshtein ...


2

In many cases, the entire HTTP request (not just the password) is padded, by virtue of the fact that the request is sent using SSL/TLS. At the heart of SSL/TLS, symmetric AES encryption is used. AES requires blocks that are each 16 bytes in length. So all requests must be padded to a length that is a multiple of 16 bytes, before they can be sent over SSL/...


2

It is not a good idea to store sensitive data in your iCloud, as Apple still own your private key. I recommend you to use Cryptomator to encrypt your cloud files. Otherwise, there are many alternatives with zero-knowledge feature you can use, such as CryptPad and NextCloud.


1

One trillion passwords per second sounds like a good rule of thumb and jibes with the number I found when researching my table of pw cracking times in 2015 (I found an estimated 23 billion per second per node, which is plausible since the NSA could easily have a few dozen nodes). When calculating this sort of thing, I prefer to assume Moore's Law applies ...


1

Password hashes are designed so that even small changes in text result in nearly random results. Once you add a salt, which all password hashing schemes should use, even if you used the same password, the hash would be different.


1

This technique has very low entropy and is not wise to use. You'd have to look at word frequencies; you'll have a lot of the small common words like articles and conjunctions ("a", "the", "and", "also"). Then you'd have to look at the frequency of each word's first letter, as weighted by the word's frequency. Word ...


1

Is character restriction ever a safe mechanism against code injection If character restrictions is a sufficiently secure protection against code injection depends on the specific implementations and what exactly it is intended to prevent. If any characters suitable for injection are still allowed, then the restriction is obviously not sufficient. Which ...


1

There isn't really an off-the-shelf way to do this, at least without a pretty complicated mask rule in hashcat, but it's trivial to write up some code to do it. Here's some C# that very quickly builds a wordlist using the scheme you described: interface IMutator { IEnumerable<string> Mutate(string input); } static class MutatorExtensions { ...


1

It's entirely specific to the system, not only in terms of the specific UEFI BIOS implementation that was used, but also to the motherboard. It also depends on which password you're talking about - there could be a supervisor password (stops access to setup/config menus at boot), power-on password, and/or a disk password. Some vendors are known to have hard-...


1

The code generating random-character password is short, simple and comprehensible. It does not depend on external data or libraries. A good start when you try to make it secure. A code that is expected to generate phrases will be more complex, will require access to an external dictionary database (and probably even a grammar rules database). Quite a few ...


1

No, this is not a problem. 1. Brute-forcing would start with shorter passwords Depending on implementation there can be padding, see the RFC. But even if there is no padding in protocol, you don't have to use it. Suppose an attacker can send as many requests as technically possible, and the application can process them without any limits. We don't consider ...


Only top voted, non community-wiki answers of a minimum length are eligible