Talk:Password strength/Archive 2

Archive 1

Archive 2

Removal of "case senstitive passwords"

I would like to remove this section. Firstly, it contains no citations, and states several dubious facts. Secondly, it contradicts most of the sources that we do have. In particular:

It is often argued that

These are Weasel words.

hurt usability and cause users to write down passwords without substantially improving password strength.

No source that we have supports this. Sure, some sources admonish written down passwords, but they don't suggest that effects the strength of the password.

In theory, case sensitivity nearly doubles the number of characters available for passwords.

Inaccurate: dependent on context. If using only lowercase, it exactly doubles, not nearly. Out of 95 charaters, uppercase represents only 27% of the total.

Doubling the size of the alphabet makes each symbol one more bit of information, thus adding one bit of information per character.

No, that isn't how exponential math works.

I could go on, but this should be sufficient? --Musides (talk) 17:17, 11 April 2008 (UTC)

I agree that this is sloppy writing. I've had it on my to-do list for quite a while. So much to-do, so little time.

But, I suggest that the issue of allowing both cases is relevant to increased brute force resistance, and that this point id worth making for the benefit of the Gentle Reader attempting to decide on a password or attempting to develop an opinion about the local acceptable password policy for one of his/her systems. I think that this would be best handled by a section discussing such policies and their effect on password choice. Not be a wholesale deletion of this section and its content as punishment for poor writing. ww (talk) 17:58, 11 April 2008 (UTC)

Character selection isn't just a matter of brute force, it is relevant for any cracking method. So, we can make a section on character selection, I suppose, and talk about why it matters in detail. That seems fair enough. --Musides (talk) 18:38, 11 April 2008 (UTC)

By character selection I presume you mean something like universe of choice. If so, I think I agree, but in general I think this subject deserves very little coverage as, once understood, it's trivial and is mostly relevant to acceptable password policies imposed on users. It is the easiest aspect of password choice to discuss, which accounts for the journalistic verbiage devoted to it, almost all skew to actual resistance to brute force attack, and is entirely misleading in concentrating on this one measure of password strength to the neglect of other issues which are harder to write about in a journalistic context. We, not being limited to that context, should do better by our Readers. ww (talk) 20:17, 11 April 2008 (UTC)

<-- The WP ASCII article notes 7 national characters, and I remember writing a paper on ASCII (ca '80) which listed 4 national characters. Without further research, for which I haven't the time just now, I left it indeterminate, which I suspect is correct anyway, given the proliferation of ASCII variants. As for the no spaces in passwords typical policy, none of the systems I'm currently using allow spaces. I seem to remember that DEC's VMS didn't either, original Unix did not, and DEC's RSX and RSTS didn't either. Some website registration might, I suppose -- not much experience with them-- but this point is ot worth a dubious or citation needed flag. No harm, no foul -- there's no violation of WP purity in equity here. There is a useful flag for the Avearge User's brain that the permitted characters list may be odd. A useful note to make, though not worth much wording. ww (talk) 22:10, 11 April 2008 (UTC)

Case sensitive passwords hurt usability without substantially improving password strength.

Reference: Diceware FAQ: To Capitalize or Not to Capitalize? --68.0.124.33 (talk) 19:51, 27 July 2008 (UTC)

Hello

Hi, I saw your help request on the WikiProject Computer science talk page.

A brief review of your exchange shows that you indeed have irreconcilable differences. I believe that improving the article requires one of you to relinquish control. As you both have noted, if that does not happen the article will have to remain in its current state. Obviously neither of you can decide for the other whether they will relinquish control; each of you can only decide for yourself. Or the article can remain in its current state. As you wish. --slashem (talk) 11:21, 22 July 2008 (UTC)

I also was asked to add my 2 cents to this discussion. I agree the page is confusing, but in part, this is because the subject is problematic. One can talk with precision about the strength of passwords that are randomly generated and one can talk about passwords that are relatively weak. But the most common case of human generated passwords is difficult to quantify, though opinions abound. Given that this is a controversial area, I think we should, per Wikipedia policy, stick to sourced material. I think there is enough published material for a balanced article. (e.g. NIST SP 800-63 Appendix A) As I understand our policy, we can exhibit straightforward calculations based on published formulae to explain things as needed. Also we can explain in the intro that there are tradeoffs on usability without getting into the question of writing passwords down. It's probably worth looking over the entire coverage of password issues on wikipedia. I created the to collect the various articles and reduce the clutter at authentication methods. I'll take a pass at editing the article.--agr (talk) 18:11, 9 September 2008 (UTC)

Password best practices

Say you are limited to 8 characters in length for a password, would a password like P!3*=$&x (1 uppercase alphabetic character, 1 lowercase alphabetic character, 1 numeric character and 5 symbol characters) be more secure than P!3C=f5x (which contains 2 of each type of character) or the other way around? Sites like Password Meter give the former a higher score than the latter (the first example given actually receives the highest possible score for an 8-character password) but it would seem to me that there would be more entropy if there was a uniform distribution of all types of characters, rather than when the majority of them are of the same type. Am I correct in thinking this, or have I overlooked something? Is anyone able to offer some insights? --77.250.113.183 (talk) 02:08, 23 July 2009 (UTC)

You have overlooked something. First, consider that any password, however chosen, which can be guessed by an attacker is weak. For the attacker there is insufficient entropy. Your driver's license number or license plate, perhaps? No matter what the password metere site says, and what are you doing sending a password off to some web site (run by?) anyway, over a public Internet?!!!

I understand your concern, but no data is actually transmitted to the site I referenced. The algorithm it uses is written in Javascript and executed locally. If you don't trust it: load the page, disable your Internet connection and enter some passwords. You'll see it'll still work as normal. I absolutely agree with you that I would never trust a site that requires me to submit my password for evaluation. --77.250.113.183 (talk) 14:26, 27 July 2009 (UTC)

Second, the issue is not what characters are included in a password, but the universe of characters from which those used were chosen, and how they were chosen. Randomly is best, of course, as it makes the attacker's life maximally difficult. Random is not so easy to arrange -- see our articles on random number generators and pseudo random number generators. A random choice will often include bits and pieces which do not look random, just as a random series of coin flips will have runs of heads and runs of tails. Don't look very random, but if they are deleted as part of a password policy than the attacker's universe from which to choose has been made smaller and easier. Thus a password of aaaaaa is a possible random choice for a 6 character password. It's no likely to be found than any other in a simple brute force search -- if the searcher has concluded that users are really choosing randomly.

I think I'd not pay too much attention to password meter, as it seems to be using a bogus algorithm to evaluate passwords and, in violation of any good sense of security at all, inviting users to pass them over the Internet to our jolly program. And perhaps to pirates as well, hiding behind that program.

Information entropy is a tricky business, dealing as it does with the degree of surprise at the attacker's end. A mathematically sophisticated attacker might recognize a digit sequence from pi or e, while for the English majors amongst us, this would be quite random looking. And this despite the randomness of the digits in pi (last time I heard, anyway).

And finally, even if password meter were to have been right, the passwords you suggest are sufficiently unmemorable that they will surely be written down in some convenient place, which will likely reduce security (or ease of access to the unauthorized) to nil. Not a good idea. ww (talk) 07:08, 23 July 2009 (UTC)

Many experts dispute the notion that passwords should not be written down. Typical users today have dozens of password accounts. It's more important that users pick strong passwords and use different passwords for those accounts where security matters. I agree that random passwords are best. I push the idea of generating them using dice, which is not that hard. Even in situations where the password must be memorized, it's best to invent numonics after the password has been generated, for example: "Peter bangs three times equaling money and x" for the first example. I'm curious as to what system today forces you to use passwords no longer than 8 characters? --agr (talk) 03:32, 24 July 2009 (UTC)

Yes, I agree. I used to have a single password for many accounts but have since moved to lots of different ones which I have simply written down on a piece of paper. In the event of one account being compromised, at least all my others will remain safe. I'm not particularly worried about some attacker breaking into my home to steal the paper holding my passwords.

And, believe it or not, there are still systems being used today that do not allow for more than 8 characters for passwords, even when that is the recommended minimum length these days. One of my ISPs, for example, limits password length to 8 characters and does not allow any special characters besides _ - and . --77.250.113.183 (talk) 14:26, 27 July 2009 (UTC)

removed suggestion for password generatin

This suggested good practice is not. Using a username as the plaintext for any encryption algorithm is poor practice as

• it sets up a possibility of a known plaintext attack on the algortihm
• it uses what is almost inevitably too short plaintext further easing such an attack
• the algorithm suggested does not have a secret key, violating Shannon's Maxim and Kerchoff's Law
• the algorithm suggested is so inherently weak that there are many people who have taught themselves to read Rot13 text on sight
• the algorithm works only on languages with 26 letters in the alphabet
• the algorithm does not accommodate non-alphabetic characters
• the algorithm's output is easily distinguished from a random oracle and so is very weak from that perspective as well.
• ...

For all these reasons, this proposal will have insufficient entropy to make an attacker's life very difficult at all. Just the opposite of what a strong password should do at an absolute and ineluctable minimum.

Not a good idea and not a good practice. ww (talk) 09:13, 20 August 2009 (UTC)

Lawyer's point of view

Nearly everything I read on this subject, including nearly all of this article, is written from a lawyer's point of view. The user's point of view is more like this: Most websites that demand a user id and a password do so for no obvious reason, so the more obvious the password, the better. If we choose 50 really long passwords, full of random letters and special characters, change them every month, and never write them down, then why wouldn't the next logical step be to throw the computer away? Recite from memory the license plate numbers of 50 friends for me, and then I'll take you seriously. Isn't the risk that someone might impersonate me at some obscure website trivial, compared to the alternative risk that I won't be able to get back into the website at all? Why would James Bond want to impersonate me anyway, at any site other than online banking for instance? Yeah, I know, this is WP:OR. Art LaPella 00:43, 8 May 2007 (UTC)

I agree with some of these sentiments. Passwords are used these days for so much useless trivialities just because they can be. I personally don't give a rat's aspirin if someone stole almost any of my passwords. Who really cares what Bill Roper, aged 19 has in his Hotmail account? Online e-mail accounts are almost universally disposable anyway, if it was compromised you'd just abandon it and set up another. And who wants to post in HypAluvA12s place on any given forum? Unless you're at work or logging on to a shopping or bank website, they're all pretty meaningless. The chances that anybody would care about finding out one of these passwords, to one of these sites, and for just one user is infinitesimal. The over-use of passwords by organistaions and websites that don't need them is tune with the mass hysteria that's going on all over the world to do with computer security. Shouldn't this be mentioned on this article? It doesn't say anything about the fact that not all passwords are serving a purpose. Mr.bonus 13:48, 8 August 2007 (UTC)

Email is often used in resetting or recovering passwords for other systems. If someone gets access to your email, they may be able to get access to your bank account.

Also, I don't see how this has anything to do with a lawyer's POV. 68.123.111.95 (talk) 03:01, 12 July 2010 (UTC)

Password strength checkers

Why would the link http://www.pwsecurity.de deleted? — Preceding unsigned comment added by 62.180.110.166 (talk) 10:21, 18 August 2011 (UTC)

There are a wide variety of password strength checkers available. The one listed in the external links sections (http://www.passwordmeter.com/) may not be the best choice. I just did a quick and dirty test and found that it gave the following ratings:

qbhekbeiybwvfkpyglenebekwinzhbwuqazwsxedrfvtgbyhn = 50%

qbhekbeiybwvfkpyglenebekwinzhbwuqazwsxedrfvtgbyhnnnnnn = 45%

12Ab! = 50%

Clearly the second password is stronger than the first and the third is much weaker.

Guy Macon (talk) 18:54, 21 May 2011 (UTC)

I find password strength checkers dubious at best. They usually test for compliance with rules about mix of characters and the like in ways that users tend to circumvent. And there is the even more serious problem of trusting the ppassword strength checkers software and any over-the-internet links involve in the checking process. I'm inclined to remove any links to password strength checkers.--agr (talk) 19:14, 22 May 2011 (UTC)

According to Password Haystacks which does not measure probability (how can you measure that anyway?) but entropy, the strength is following:

qbhekbeiybwvfkpyglenebekwinzhbwuqazwsxedrfvtgbyhn = 2.24 × 10⁶⁹ (230 bits)

qbhekbeiybwvfkpyglenebekwinzhbwuqazwsxedrfvtgbyhnnnnnn = 2.66 × 10⁷⁶ (253 bits)

12Ab! = 7.82 × 10⁹ (32 bits)

--193.29.76.37 (talk) 10:04, 17 August 2011 (UTC)

If you check qbhekqbhekqbhekqbhekqbhekqbhekqbhekqbhekqbhekqbhe (which has the same length as your first example, 49 characters, but just repeats the first five characters) on the GRC site you get the same answer, 2.24 × 10⁶⁹, even though this is clearly a weaker password than the first. That's my problem with password checkers. They give very definitive answers (complete with times to crack in billions of trillions of years) that are often nonsense. It's a lot simpler to do what our article suggests, multiply 49 letters * 4.7 bits/letter = 230.2 bits (assuming random letters), without all the mumbo jumbo of the password checker.--agr (talk) 12:00, 18 August 2011 (UTC)

How weaker it is? During exhaustive search, searching for repeating patterns of gibberish would cost much more time before even testing the first five non-repeating characters because the attacker does not know how many times and how many characters to repeat. Cracking password is not a game of Mastermind, the attacker never knows how close they is or whether even the smallest part of their pattern is correct. That is also what the site states and why it calculates entropy so simply; it *is* so simple. On the other hand, dictionary attacks are outside scope of that checker because entropy of such passwords is very hard to estimate (it depends on the dictionary you use as well as language of the user) --193.29.76.37 (talk) 17:09, 18 August 2011 (UTC)

You get, say, 7 bits for the overall length of the password and 4 bits for the repeat pattern length plus 4.7 bits times the number of letters in the repeat. So searching all repeating patterns up to 5 characters is maybe 39 bits. That's assuming the attacker knows how his target goes about picking passwords, of course, but there are lots of ways he could discover that. I can also imagine a generalized repeat pattern generator using some production rules that would test all sorts of combinations. It might take a while to get to this one, but not the 7.13 billion trillion trillion trillion centuries that the GRC site suggests. If you read their fine print, they are not even claiming to calculate password entropy, just how many possible passwords there are of the same length and character set.--agr (talk) 03:50, 19 August 2011 (UTC)

Protection against Key-logging?

I am not clear as to how a good password would give protection against key-logging. Have I missed the point? Regards, Ronpedia (talk) 09:46, 8 September 2011 (UTC)

It wouldn't, of course. Is there some place in this article that suggests to you it would?--agr (talk) 13:05, 8 September 2011 (UTC)

objection on pattern passwords

"Environ Passwords"

1. The mandation of these by the UK government seems to have become an Internet myth. This needs citation.

a) I have even found a "serious" paper that repeats this myth: http://www.ijcee.org/papers/001.pdf This paper quotes this wiki page as a reference!

b) This PhD student repeats this text regarding the UK government without a citation: http://www.archive.org/stream/MemorizablePublic-keyCryptographymepkcItsApplicationsversion3.0/MePKC_v3-0_djvu.txt see para 3.2.1

although at least he gives a citation for the idea of environ passwords as: Anderson, R. (2001). Security engineering: A guide to building dependable distributed systems. New York, NY, USA: John Wiley & Sons, Inc.

For the moment I will add this citation but make a note that it needs checking... — Preceding unsigned comment added by BWernham (talk • contribs) 16:23, 28 January 2012 (UTC)

Many of you say that pattern passwords can be easily guessed, by a varied of materials.

I myself doesn't agree, as the password like 13795, is it easily guessed?

It is just basically a pattern on the number square, but most hackers don't even try it out. However, i just wanted to make sure that all of you agree on it before it is being changed. —The preceding unsigned comment was added by SteveNash11 (talk • contribs) 04:09, 8 May 2007 (UTC).

Yes, this and other patterns on a Pump It Up or Dance Dance Revolution pad are easily guessed. Pseudocode follows:

for i in (1..99999999):

if hash(numToString(i)) == passwordHash:

write "Your password might be " + numToString(i) + linebreak to log

Computers can process this loop very quickly, especially on systems that can distribute for...in to multiple processing cores in a machine or to multiple machines in a cluster. --Damian Yerrick (talk | stalk) 12:29, 8 May 2007 (UTC)

Yeah, even with a numeric sequence twice as long (viz., 1652479803), it takes only seconds to find it:

#include <stdio.h>
int main()
{
  unsigned int i, pass = 1652479803;
  for (i = 0; i < 2000000000; ++i) {
    if (i == pass) {
      printf("Password: %d\n", i);
      break;
    }
  }
}

64.234.1.144 (talk) 04:46, 1 April 2008 (UTC)

It seems as though this has already been corrected in the article. A reference, however, would be ideal.--Musides (talk) 19:07, 1 April 2008 (UTC)

"Passwords are dead"

Is this relevant to this article? Toccata quarta (talk) 14:57, 11 September 2013 (UTC)

Base58 Encoding is not included in the desired password entropy table

I generate all my passwords for my accounts with random dice role. I have a 6 sided die and a 10 sided die, which allows for 60 possibilities. When two of those possibilities are rolled, I re-roll both die to guarantee evenly distributed entropy over 58 possible outcomes. I then map each of the 58 possible outcomes to a character in a base58 using the same subset of characters in Bitcoin's base58 encoding mechanism. From this I gather the following amounts of entropy:

bits	bytes	base10	base58
6	1	2	1
12	1	4	2
18	2	5	3
23	3	7	4
29	4	9	5
35	4	11	6
41	5	12	7
47	6	14	8
53	7	16	9
59	7	18	10
64	8	19	11
70	9	21	12
76	10	23	13
82	10	25	14
88	11	26	15
94	12	28	16
100	12	30	17
105	13	32	18
111	14	34	19
117	15	35	20
123	15	37	21
129	16	39	22
135	17	41	23
141	18	42	24
146	18	44	25
152	19	46	26
158	20	48	27
164	21	49	28
170	21	51	29
176	22	53	30
182	23	55	31
187	23	56	32
193	24	58	33
199	25	60	34
205	26	62	35
211	26	63	36
217	27	65	37
223	28	67	38
228	29	69	39
234	29	71	40
240	30	72	41
246	31	74	42
252	31	76	43
258	32	78	44
264	33	79	45
269	34	81	46
275	34	83	47
281	35	85	48
287	36	86	49
293	37	88	50
299	37	90	51
305	38	92	52
310	39	93	53
316	40	95	54
322	40	97	55
328	41	99	56
334	42	101	57
340	42	102	58
346	43	104	59
351	44	106	60
357	45	108	61
363	45	109	62
369	46	111	63
375	47	113	64
381	48	115	65
387	48	116	66
392	49	118	67
398	50	120	68
404	51	122	69
410	51	123	70
416	52	125	71
422	53	127	72
428	53	129	73
433	54	130	74
439	55	132	75
445	56	134	76
451	56	136	77
457	57	138	78
463	58	139	79
469	59	141	80
474	59	143	81
480	60	145	82
486	61	146	83
492	62	148	84
498	62	150	85
504	63	152	86
510	64	153	87
516	64	155	88

I feel it is important to include base58 because of the properties of avoiding ambiguous characters such as 0OIl that appear the same in many fonts. This encoding mechanism is important for recorded entropy because passwords are often written and shared. When I create a one time pad and distribute it to my associate, I distribute it encoded as base58 to avoid potential human error decoding the written or printed pad. base58 stores marginally less information than case sensitive alphanumeric and has the benefits of removing ambiguity in the encoding/decoding process. Is there any reason to refrain from adding a column for base58 encoding and entropy density? — Preceding unsigned comment added by 2602:306:8020:CD10:9DF1:1A9:1470:8986 (talk) 15:41, 28 September 2014 (UTC)

On Wikipedia, the standard for inclusion is not usefulness, but rather verifiability and reliability. In my opinion, the fact that Bitcoin uses Base58Check encoding[1] is a good reason to include it in this article's "Entropy per symbol for different symbol sets" table. I suggest "Bitcoin/Ripple Base58 encoding" as a title for the new entry. --Guy Macon (talk) 18:53, 28 September 2014 (UTC)

XKCD does it again

The cartoon is a good thought piece but it turns out that the frequency count of English words with 5, 6, 7, or 8 letters in them, deeply weaken the true entropy of the approach. But, to say so in a Wiki Article would be to site original content and thus is not allowed. Even if I have tools that can prove it. It would not matter that I actually am paid to by firms to do Pen Tests of the PCI DSS (Credit Card Processing) Networks and to have real world samples of passwords, dictionaries, corporate specific samples of entire password file and really can measure the truth behind both the good and questionable source material found in this article. The "HorseBatteryStaple" password is a lot more vulnerable than the XKCD author computes; even though I love its style and use it to train and provoke conversation. All my password strength advice requires my students to have their password cracked after training. My MacBook Pro achieved 6 billion password tests per second on August 13, 2013. The cracking brute force rates are moving much faster than this article's quoted references can keep up. NIST's standard of 80 bits is better updated. Moore's law: NIST in 1970 said that a complex 8 place password would reasonably strong; 40 years later that would be 4 digits longer for equivalent strength, so 12 place passwords for 2010. By 2020, it will be 13 place passwords. All this, one could deduce without owning a single password cracking bed setup.

Password grading algorithms, even those used by Google, are still suffering from Naive assumptions. But, Google is not going to print a research paper on that any time soon. Original work on why firms do not adopt password salt practices would still be too cutting edge, because I would have to reference works that do not meet Wiki Standards for either obviousness, or quality links.

So, it is Password Strength assessment by Cartoon, and password patterns like "FakeStrongPassword"; the truly sad part is that "HorseBatteryStaple" is better than the 10% of the password users who are using the corporate help desk temp password as their actual password -- supposing that since it came from the help desk IT professionals, that these know what they are doing. — Preceding unsigned comment added by Arctific (talk • contribs) 15:11, 23 October 2014 (UTC)

Does this comic, published today, not spell out the essence of password strength? im embarrased i never thought of this. its so simple. I wish this could count as a reliable source, though, logically, its sound, who would cite a comic for this fact?(mercurywoodrose)76.232.10.199 (talk) 07:54, 10 August 2011 (UTC)

Please see WP:XKCD. OhNoitsJamie ^Talk 16:53, 11 August 2011 (UTC)

WP:XKCD (which is an essay) deals with popular culture and trivia references. xkcd.com/936 directly addresses the subject of this article and illustrates the issues very well. If it didn't have a non-commercial CC license, we'd add it to the article in a heart beat. The EL is completely appropriate. --agr (talk) 19:02, 11 August 2011 (UTC)

And it does not meet WP:Reliable sources. I'll be happy to take it to the RS noticeboard if you continue to dispute it. Regarding the other links, we don't need that many password strength checkers. OhNoitsJamie ^Talk 19:33, 11 August 2011 (UTC)

There is no requirement that external links be reliable sources. On the contrary, WP:EL says "Links to be considered: 4. Sites that fail to meet criteria for reliable sources yet still contain information about the subject of the article from knowledgeable sources." Randall Munroe is widely considered knowledgable on technical topics and here succinctly summarizes the material in this article. However, I agree with you on strength checkers. --agr (talk) 21:21, 11 August 2011 (UTC)

Then I'll take it to the Spam board. There is plenty of consensus that XKCD links are rarely appropriate for articles (with exceptions such as Corey Doctorow, as mentioned in WP:XKCD. OhNoitsJamie ^Talk 21:50, 11 August 2011 (UTC)

Rarely does not mean never. I've given you clear reasons why this xkcd contributes useful information to this article. You keep changing your story. I'm restoring the link. Take it to what ever board you like. --agr (talk) 15:41, 12 August 2011 (UTC)

As the author of WP:XKCD, this was exactly what it was written for. When reliable secondary sources back up Munroe's point (explicitly) or document something of real-world impact happens which references the strip, this is worth discussing. Not until. Chris Cunningham (user:thumperward) - talk 00:12, 16 August 2011 (UTC)

GRC's Password Haystacks has a pretty good explanation why password entropy is mostly based on length as well as a tool to estimate password entropy --193.29.76.37 (talk) 09:58, 17 August 2011 (UTC)

That's not disputed. What is disputed is that this comic strip has unique educational value that we couldn't include in the article body. The facts within the strip can be trivially presented here in text, so we're left with the proposition that the comic strip is in some way noteworthy in itself, and it isn't: it's just one of nearly a thousand stick figure comics drawn by a guy who happens to be very popular with the type of person who edits Wikipedia. The essay tries to illustrate cases where such links are appropriate, and this isn't one of them. Chris Cunningham (user:thumperward) - talk 10:32, 17 August 2011 (UTC)

Memorizing a multi-word passphrase by visualization techniques is not so trivial to make explain in text form. A clear graphic depiction by a respected artist is valuable for our readers and meets the requirement of WP:EL: "Sites that fail to meet criteria for reliable sources yet still contain information about the subject of the article from knowledgeable sources." I'd invoke WP:PILLARS "The principles and spirit of Wikipedia's rules matter more than their literal wording, and sometimes improving Wikipedia requires making an exception to a rule." except that WP:XKCD isn't even a rule, it just an essay. The test should be does having this external link improve the project or not? As one of the speakers at the recent Wikimania said "we need to relax a bit and be less conservative".--agr (talk) 16:34, 17 August 2011 (UTC)

We might want to ask the author of XKCD for permission to use that comic as am embedded graphic rather than linking to it. It does make an important point. Considering the fact that the Wikipedia login screen tells users that this page contains advice about choosing a password, we really don't want them to follow the ancient "numbers, letters, and control characters" advice instead of the modern "Long, unique, and easy to remember English sentences" advice. --Guy Macon (talk) 10:42, 9 May 2013 (UTC)

trick passwords

Although the arcticle said that trick passowrds, like password, or in any other simlilar way is a bad password, cause they might able to guess it. But I don't think so. A person can name a password: wordpass.

That is a suggested password in my opinion.

pls list what you think. Any password combination that contains the word pass either in the password or in any Microsoft file with content even considering the concept of accounts or passwords can be picked of hard drive and has a 1/20 chance of actually listing account and password combinations in that file.

password combinations with anything approximating "pass" are deeply close to the worlds most guessable combination. From the Sony 1 million password population, "password" itself was the single most likely password in that entire user base of supposedly computer literate game players. Even native speakers of Asian rim non-english languages are likely to use it. At 6 billion trial passwords per second, the most probable passwords crack first, then the dictionary words of every language that has a written dictionary with leet variation of each choice. Simply modeling each language as have 100,000 words, with 10 Leet combinations per word. Then 6 billion passwords/sec / 100,000 words/language /10 leet variations/password = room for 6,000 languages in the first cracking second. Note: English words that are seven place long top out near 6,000 words. — Preceding unsigned comment added by Arctific (talk • contribs) 15:51, 23 October 2014 (UTC)

—The preceding unsigned comment was added by SteveNash11 (talk • contribs) 04:00, 8 May 2007 (UTC).

• Try using the most absolute random word in the dictionary!!!!! I know what it is, but I ain't sayin'!!!!! (not-so-evil laugh) Chef Clover MyTalk 14:16, 8 May 2007 (UTC)

• • Of course, there's always the simple double-letter-doohickey, like "rraannddoomm." (giggles) Just try not to make sure that it's one of the most used passwords listed in the article, please. Chef Clover MyTalk 23:32, 8 May 2007 (UTC)

• Common permutations of dictionary words are standard things to try with most cracking software, and have been for ages: as long ago as 1993 I pointed out to my university lecturer that his password, "drowssap" was insecure and had been cracked in seconds. Concatenations of two short words, like "wordpass" are equally insecure. So, no: if you have a problem with people cracking your account, don't use passwords like this. If you don't mind being hacked, then by all means use the easiest password to type: something like "12345678" or the letter "a" repeated for long enough to meet the minimum password length. Just be aware that these common and simple terms will be in the dictionaries of any decent cracker. —Preceding unsigned comment added by DewiMorgan (talk • contribs) 20:44, 13 December 2007 (UTC)

I think you, and people like you, can butt the hell out of my password generation. I'll take care of that, and I don't want someone literally forcing me to make good passwords that I will not remember. The point, as far as this discussion is concerned, is that this is a common feeling among internet users (that is, the people I have talked to) and it is not addressed in the wikiarticle at all, and needs to be (preferably under "criticism", as per wiki tradition). 74.197.184.250 (talk) 18:51, 14 December 2013 (UTC)SethBrunson

Binary/bits/byte/hexidecimal.

Added Binary byte to the symbol set table and added byte in parenthesis to the examples table, and added a short line explaining that a binary byte is usually expressed using two hexidecimal characters, also added 8 bit (1 byte) to the example table for reference. Hopefully this will be more informative for those not too familiar with bits and bytes and hex etc. Sure it's uncommon for binary passwords to be entered directly but they can be (as Hexidecimals) via copy'n'paste or password managers, and people should have a better grasp of how much 4 bytes is vs 32bits as far as storage size/space goes. Rescator (talk) 03:21, 15 December 2014 (UTC)

Possible Image for page

This page is flagged as needing an image on it. See https://commons.wikimedia.org/wiki/File:Password_Strength.png as it seems generic and simple enough for the job. — Preceding unsigned comment added by Andrdema (talk • contribs) 16:35, 14 March 2015 (UTC)

Clarification, rationale or citation for this section

I have a question regarding this section: "moving from never changing one's password to changing the password on every authenticate attempt (pass or fail attempts) only doubles the number of attempts the attacker must make on average before guessing the password in a brute force attack - one gains much more security just increasing the password length by one character than changing the password on every use."

It appears wrong to me, expected guessing time would actually be infinite for the second approach. Can someone clarify, or provide a rationale or citation for this section? --Bananarama9000 (talk) 12:15, 27 March 2015 (UTC)

Maximum guessing time would be infinite for the second approach, but not expected guessing time.

Consider a two character 0-9 password. It has possible values ranging from 00 to 99 -- so there is a 1% chance of getting it on the first guess, a 50% chance of getting it by the 50th guess, and a 100% chance of getting it by the 100th guess. More importantly, if you have guessed wrong 50 times your odds of getting it on the next guess is 2%, if you have guessed wrong 90 times your odds of getting it on the next guess is 10%, and if you have guessed wrong 99 times your odds of getting it on the next guess is 100%.

Now consider the case where it changes after every guess. Now each guess has a 1% chance of being right no matter how many bad guesses you have made already. And there is tiny chance that you might be really unlucky and guess wrong a million or even a billion times in a row. So it's stronger, but not by much.

I didn't calculate it out to see if it is exactly twice as strong, but that seems about right. However, even if I did, that would be WP:OR (see WP:CALC). We really need a citation to a reliable source backing up that particular claim. --Guy Macon (talk) 15:04, 28 February 2016 (UTC)

External links modified

Hello fellow Wikipedians,

I have just added archive links to one external link on Password strength. Please take a moment to review my edit. If necessary, add {{cbignore}} after the link to keep me from modifying it. Alternatively, you can add {{nobots|deny=InternetArchiveBot}} to keep me off the page altogether. I made the following changes:

• Added archive https://web.archive.org/20100610000727/http://uc.iupui.edu/uploadedFiles/Learning_Center_Site/Mnemonic%20Devices.pdf to http://uc.iupui.edu/uploadedFiles/Learning_Center_Site/Mnemonic%20Devices.pdf

When you have finished reviewing my changes, please set the checked parameter below to true to let others know.

Y An editor has reviewed this edit and fixed any errors that were found.

• If you have discovered URLs which were erroneously considered dead by the bot, you can report them with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—^{cyberbot II}_{Talk to my owner:Online} 06:31, 15 January 2016 (UTC)

Checked. --Guy Macon (talk) 15:10, 28 February 2016 (UTC)

Password padding

Would this be worth adding to the article? Password Haystacks" in the second half of that page about "password padding", advising that passwords should be made longer by "padding" with extra symbols e.g. full stops in addition to lower case, upper case and numbers. MetalFusion81 (talk) 09:44, 28 February 2016 (UTC)

In my opinion, this would not be a good addition for two reasons:

[1] Although I personally really like grc.com and use some of the tools there regularly, there are a boatload of websites that calculate password complexity (and by an amazing coincidence also just happen to also have some commercial product for sale). If we allow a link to one, it wouldn't be fair to exclude the others, and the article could very well end up being 90% external links, at which point they all would be removed per WP:LINKFARM.

[2] Like all such websites, grc.com relies upon an easy-to-put-on-a-webpage mathematical method, whereas real attackers use more sophisticated methods. For example, grc.com claims that...

  D0g.....................

...is stronger than...

  PrXyc.N(n4k77#L!eVdAfp9

...which in the real world is completely untrue. No rational attacker is going to attempt a brute-force exhaustive search of all 23 or 24 character passwords before trying a dictionary attack. I just checked, and my password-cracking dictionary already contains both "D0g" and "....................." (Along with "P1g", "........", "\\\\\\\\\\\\", etc.) and would find "D0g....................." in seconds. My dictionary also contains all variants of "<-><-><-><->" "[*][*][*][*]" (as well as "*.**.**.**.*", "~@~~@~~@~~@~", etc.) up to 64 characters. It had "^-^" through "^-^^-^^-^^-^" but would have missed longer repetitions of "^-^". I just added those.

The password padding idea, while clever, results in a password that can be found in a few minutes by anyone running a dictionary attack with a large dictionary on a cluster of fast PCs. --Guy Macon (talk) 14:42, 28 February 2016 (UTC)

Interesting. Let's invent a hard-to-guess password now, like this:

kwxt02158PTMwmtu5574PTKmaoZ400

Following the advice on that page, I will add some "padding" into it:

kwxt......02158P#########TMwmtu557....................4PTKmaoZ400

The second password with the padding is obviously more secure. I used full stops (periods) and hash signs (aka number signs). These passwords and others like them are too hard for most people to memorise. The grc page suggests that padding allows passwords to be easy-to-remember AND longer, given that longer passwords are more secure. I think the article should include a link to that page and mention its suggested padding method, but within the article and not as an external link to avoid WP:LINKFARM. I have seen links to the grc.com website on other Wikipedia articles, so it should be okay.

By the way, I can't help wondering how hard it can be to crack passwords of more than 20 characters? If the padding allows users to extend their passwords beyond 20 characters, this alone is more secure and better than using weak passwords and makes it harder for dictionary attacks to succeed in a reasonable time? MetalFusion81 (talk) 00:48, 29 February 2016 (UTC)

If your 20 character password is something like 8!Hiplg#+X+f$4M+n^QH (20 characters) then the grc.com page gets it right; 11.5 thousand trillion centuries to guess assuming one hundred trillion guesses per second.

In fact, 8!H+4plg#Xi+ (12 characters) will take 1.4 hundred million centuries to guess.

If you stick with a-z, qjbrsmbkmwdjwsnzquxs (20 characters) would still still take 66 thousand centuries.

Alas, qjbjwrnbksdmsmwz (16 characters) would take 14.4 years and qjbmbkrnsdjw (12 characters) would take 16.5 minutes, so length matters.

In fact, length matters a lot more than including numbers, capital letter or punctuation marks does, because adding one character makes the number of guesses the attacker has to make 26 times larger and adding 4 characters makes the number of guesses the attacker has to make 456,976 times larger.

On the other hand, a long password like SecretPasswordSecretPasswordSecretPassword would be quickly cracked on an ordinary PC using a modern password-guessing program. Those 42 characters are useless against a password guessing program that [A] has "SecretPassword" in its dictionary (which it will) and [B] tries all dictionary words repeated twice and three times (which it will).

Links with more information:[2][3][4][5][6] --Guy Macon (talk) 20:17, 19 July 2016 (UTC)

Run on sentence

This is a run on sentence at the 4th paragraph in the "Password Guess validation section". I am not qualified to edit it. Be kind if I am just missing the meaning of the thing.

Unfortunately, many authentication systems in common use do not employ salt and rainbow tables are available on the Internet for several such systems.

— Preceding unsigned comment added by Anorderofmagnitude (talk • contribs) 00:15, 21 August 2016 (UTC)