We’re rewarding the question askers & reputations are being recalculated! Read more.

Hot answers tagged

223

By any measure, they're wrong: Seven random printable ASCII: 957 = 69 833 729 609 375 possible passwords. Ten random alphabetics: 5210 = 144 555 105 949 057 024 possible passwords, or over 2000 times as many. Length counts. If you're generating your passwords randomly, it counts for far more than any other method of making them hard to guess.


201

The mistake here would be to believe that extra password rules increase security. They do not. They increase user annoyance; and they make users choose passwords that are harder to memorize. For some weird psychological reason, most people believe that a password with non-letter symbols is "more secure" in some ontological way than a password with only ...


182

Conor's answer is a good starting point, but if you dig into Chromium's source the situation starts to look a little bleaker (but still better than not using a password manager at all). Chrome 68 (current version as of August 1st, 2018) Up through version 68 Chrome follows FIPS 181 to generate a 15 character pronounceable password allowing uppercase ...


148

The thing is, with a 4 digit pin, entropy isn't really important. What's important it the lockout and the psychology of the attacker. The keyspace is so small that any automated attack (without lockout) would exhaust it almost instantly. What you're worried about is an attacker guessing the pin before the account locks. So assuming a sane lockout (...


120

There's a quote for you in this crypto.SE answer, by Bruce Schneier in Applied Cryptography (1996), pp. 157–8. You can also find Bruce Schneier citing himself in his blog (2009), if you want an online citation. Here is the full quote, in case of the links breaking: One of the consequences of the second law of thermodynamics is that a certain amount of ...


93

If you’re designing a cryptosystem, the answer is No. Kerckhoffs's principle states “A cryptosystem should be secure even if everything about the system, except the key, is public knowledge.” Restated as Shannon's maxim, that means “one ought to design systems under the assumption that the enemy will immediately gain full familiarity with them.” Making the ...


89

The theoretical perspective Let's do the math here. There are 26 letters, 10 digits and let's say about 10 special characters. To begin with, we assume that the password is completely random (and that a character in one group is not more likely to be used than a character in another group). The number of possible passwords can then be written as C = s^n ...


82

I'm going to barge in and talk about entropy and probability for a little bit and hopefully this will help you understand. Firstly what is probability? This is actually an open question amongst statisticians but here's the frequentialist definition: we say that if a fair coin is flipped, it has probability 0.5 of coming up heads. However, if you flip a coin ...


72

Why, indeed? Allow me to ignore that question for a moment, and answer your implied question: Should we? That is, should we continue to have users create their own password, which is often weak, instead of just having the system generate a strong password for them? Well, I am of the controversial opinion that there is a pretty strong trade-off here - ...


60

An index of entropy values (divide times by the number of nodes—state actors have lots of nodes): BIT ~RAND CRACK CRACK DICTIONARY COUNT ENTROPY CHARS MD5 PBKDF2 ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ̅ ...


53

It depends on what you mean by "readable". If you want to use only hexadecimal characters, you will need 32 of them to reach 128 bits of entropy; this line will work (using only commands from the coreutils package): head -c16 /dev/urandom | md5sum This variant produces passwords with only lowercase letters, from 'a' to 'p' (this is what you will want if ...


50

To add to Avid's excellent answer, the other key messages of the comic are: the appropriate way to calculate the entropy of a password generation algorithm is to calculate the entropy of its inputs, not to calculate the apparent entropy of its outputs (as rumkin.com, grc.com etc. do) minor algorithm variations such as "1337-5p34k" substitutions and "pre/...


46

In practical terms, no, as John's answer neatly explains. Hypothetically, if you had enough secure encryption methods to choose from, you could potentially select one method at random and use it to encrypt the data using – for example – a 256-bit key. The choice of algorithm used would need to be "added" to the key and become part of the "not to be revealed ...


43

Short answer: The more the better, but for now (2014) this is probably enough. There is an important distinction between hacking into your Gmail and cracking an offline password. If you want to hack a Gmail account by guessing the password, you can only do a few tries per second at most. Google will block thousands of login attempts to a single account in ...


41

Microsoft already has done something like this with their product key alphabet. They selected a subset of characters that are distinctive, and excluded characters that could lead to either confusion or offensive words. The 24 used are: 2346789BCDFGHJKMPQRTVWXY The 12 unused are: 015AEILNOSUZ The hyphen character is used to separate five character groups, ...


38

(Caveat: I certainly don't claim that HAVEGE lives up to its claims. I have not checked their theory or implementation.) To get randomness, HAVEGE and similar systems feed on "physical events", and in particular on the timing of physical events. Such events include occurrences of hardware interrupts (which, in turn, gathers data about key strokes, mouse ...


38

Both OpenJDK and Sun read from /dev/urandom, not /dev/random, at least on the machine where I tested (OpenJDK JRE 6b27 and Sun JRE 6.26 on Debian squeeze amd64). For some reason, they both open /dev/random as well but never read from it. So the blog articles you read either were mistaken or applied to a different version from mine (and, apparently, yours). ...


38

Let me start with an important and accurate caveat: http://dilbert.com/strip/2001-10-25 The math Looking at the actual odds, there are 62 possible characters (a-zA-Z0-9) and therefore assuming all are equally distributed that means that any given character has a ~16% chance of being a digit. You have shown us 136 characters in total which means that on ...


37

5 Diceware words = 77765 = 28430288029929701376 possible equiprobable passphrases. 9 random characters = 949 = 572994802228616704 possible equiprobable passwords. The 5 Diceware words are 49.617 times better than the 9 random characters. On the other hand, 10 random characters would be almost twice as good as the 5 Diceware words (but the Diceware words ...


36

Entropy in physics and in information science is just the logarithm (typically natural log in physics; base-2 log in computer science) of the number of equally likely possibilities, because it's generally easier to deal and think about with the logarithm of these exceptionally large number of possibilities than the possibilities directly. If I randomly ...


35

First, there is no such concept as a cryptographically secure password. The aim of a password is to be hard to guess for an attacker and how hard it should be to guess depends on how the password is used: if the account is locked after three failed attempts the password can be more weak compared to when an attacker can try an unlimited number of passwords or ...


31

If you are to abide by CWE-521: Weak Password Requirements. Then all passwords must have a min and max password length. There are two reasons for limiting the password size. For one, hashing a large amount of data can cause significant resource consumption on behalf of the server and would be an easy target for Denial of Service. Especially if the ...


30

Getting the password to the user The only times I have seen systems that set the password for the user, it is send to the user via email (obviously in plaintext), which is obviously a bad idea[*] (and SMS, Mail, etc are not that much better). So that would leave displaying the password when creating the account (which might also be a bad idea because of ...


30

This really depends on how the PIN is created: If the PIN is generated, make sure the distribution is uniform and don't exclude any combinations. That will maximize the entropy. If the PIN is chosen by a human operator, it makes perfect sense to exclude some combinations. I wouldn't go as far as rejecting half of the combinations, but if you do, you should ...


29

No, you don't increase entropy by hashing it once, or twice, or ten times. Consider entropy as it is seem from the input, not the output. You cannot add entropy using a deterministic process, as the entropy of the result does not count. Even if you have some code like this: $password = "123456"; $result = md5($password) . sha1($password) . hash('gost', $...


28

Because, as LinkedIn and other recent password leakages reveal, still the most common passwords for websites are "password", "god", "123456", etc. So you can brute-force with really short list of most common passwords. Still, you can just ban those passwords, or require long password - as possible combinations grow exponentially with the length, and ...


27

Entropy is a property of the password generation method, not the password. If you decide to eliminate repeated digits - this decision lowers the entropy compared to generating a random sequence. In fact, anything you come up with will have lower entropy than generating a random sequence. And if you believe a randomly-generated password 1111 has a low ...


27

Let's take a different crack from a monetary perspective instead of a physics perspective. Skylar Nagao at Peerio stated that: In a 2014 research paper on password memorability, security researchers Joseph Bonneau (Stanford) and Stuart Schechter (Microsoft) estimated the cost of an attack based on the total annual payout to bitcoin miners in 2013. ...


26

Password meters are no good. Well, that's a bit simplistic, so let me say it in more details: a "password meter" application like the one you used is mindless and generic; what it measures is the effort of breaking your password, using the mindless and generic strategy that the password meter author thought of. In particular, that password meter system has ...


25

Space reduction does occur, but not like that. Secure hash functions are supposed to behave like what a random function would do on average (i.e., a function chosen uniformly among the set of possible functions with the same input and output lengths). MD5 and SHA-1 are known not to be ultimately secure (because we can find collisions for them more ...


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