The most useful strategy I've seen is to use multiple authentication methods or the "a few really hard passwords + random statement for each site." Ie. you can probably memorize something like lMB^9Pl! so use that for the sites and then tack on something like lMB^9Pl!Ilikeshopping123 Then the probability of actually cracking that password is low, and unless you are being specifically targeted, even if they got that password they wouldn't immediately be able to use it on other websites. It's easy to remember because that 8 digit code you'll type everywhere, and the ending is always something cognitively easy. On 11/11/2013 1:40 PM, David Vorick wrote:

I could see this as being a good strategy if you didn't declare it, but by eliminating vowels you reduce the search space.

It's only a good tactic if people actually switching from using dictionary words to using something with higher entropy. More likely though, you'll start to see things like 'bbbddq' or 'cmplt sntnce,' and the users will still be susceptible to dictionary attacks.

It's important to remember that a good dictionary attack has a dictionary that is much larger than a list of words in different languages, it also has common patterns. This sort of restraint probably reduces the usage of dictionary words but increases the usage of other common patterns.

I don't like it.

On Mon, Nov 11, 2013 at 7:29 AM, J.A. Terranson <measl@mfn.org> wrote:

...

Mildly interesting, for those who have an interest ?

//Alif

-- Those who make peaceful change impossible, make violent revolution inevitable.

An American Spring is coming: one way or another.

---------- Forwarded message ---------- Date: Thu, 7 Nov 2013 14:01:15 -0500 From: William Arbaugh <warbaugh@gmail.com> To: dailydave@lists.immunityinc.com Subject: [Dailydave] Don't use vowels in passwords!

According to the Defense Finance and Accounting Service (DFAS), you shouldn't use vowels in your password!

The DFAS web site myinvoice.csd.disa.mil is instituting new password requirements starting tomorrow. The details can be found at the site (if you're willing to read a PDF hosted by DOD that is).

DFAS brings us two significant improvements to password/PIN security by forbidding the use of vowels, and requiring that password/PINs be EXACTLY 15 characters long (no more, no less). I'd guess that the first requirement is to prevent people from using dictionary words. The second requirement is probably due to some obscure issue with their use of an Oracle Java front-end.

This is from a web site that until recently ( and I believe still does) required the use of IE and Java 6. Logging in use to require clicking through no less than 3-4 security warning pop-ups. _______________________________________________ Dailydave mailing list Dailydave@lists.immunityinc.com https://lists.immunityinc.com/mailman/listinfo/dailydave

https://www.schneier.com/blog/archives/2013/06/a_really_good_a.html The xkcd comic doesn't really apply anymore. Dictionary attacks have gotten to the point where they can crack 'momof3g8kids' and 'Coneyisland9/,' and apparently have dictionaries breaking 100 million words. As password attacks get better and better at predicting human patterns (and hardware gets faster), you are going to need to completely generate your passwords at random in order to defend against dictionary attacks. Which means the current password model is broken, as we all know it has been for a while. Why isn't there a stronger effort to replace it with something like a universal public key system? On Tue, Nov 12, 2013 at 4:01 AM, rysiek <rysiek@hackerspace.pl> wrote:

Dnia poniedziałek, 11 listopada 2013 15:29:13 Kelly John Rose pisze:

...

The most useful strategy I've seen is to use multiple authentication methods or the "a few really hard passwords + random statement for each site."

Ie. you can probably memorize something like

lMB^9Pl!

so use that for the sites and then tack on something like

lMB^9Pl!Ilikeshopping123

Then the probability of actually cracking that password is low, and unless you are being specifically targeted, even if they got that password they wouldn't immediately be able to use it on other websites. It's easy to remember because that 8 digit code you'll type everywhere, and the ending is always something cognitively easy.

Oblig. XKCD: http://xkcd.com/936/

-- Pozdr rysiek

Do people actually use vowels in their passwords? I thought they turned them into 0, 1, 3, 4, and other l33t characters to satisfy "must have a number" rules. Salted hashes are important, of course, but if you only need to crack one user and not all of them, then a dictionary attack with a "Top 1000 Wimpy Passw0rds" list isn't going to have much trouble, and if you need a list of "A Million Wimpy Passwords and 100,000 Normal Variations" there's probably one out there, just in case there isn't some user who used "abc123" or "123456" or "password". At 08:17 AM 11/12/2013, Guido Witmond wrote:

On 11/12/13 17:00, David Vorick wrote:

...

Which means the current password model is broken, as we all know it has been for a while. Why isn't there a stronger effort to replace it with something like a universal public key system?

Plug: You mean, something like this: http://eccentric-authentication.org/ Regards, Guido.

There's Bellovin and Merritt's EKE Encrypted Key Exchange from ~1993 https://en.wikipedia.org/wiki/Encrypted_key_exchange for which the patents expired in 2011 and 2013.

The xkcd comic doesn't really apply anymore. Dictionary attacks have gotten to the point where they can crack 'momof3g8kids' and 'Coneyisland9/,'

Your examples suggest you're referring to that article that alleged dictionary attacks can crack 90% of hashed database passwords offline in 4 hours, right? Can't remember the site. They neglected to say they were dealing with unsalted md5 hashes. A password of good length, stored using a *password hash*, is pretty secure against attack. 'Good length' here is 20 characters or more, if you ask me..but the "true" entropy of a passphrase is not merely the length or character value, but number of words. So a 4-word 20-character passphrase is probably slightly weaker than a 5-word one, because pattern-based or markov-based brute-forcers may have an easier time working through 4-character passphrases. All speculation, but still. A password hash that is uniquely salted forces an attacker to brute force every possible password again for each attacked password. A password hashed with a scheme like scrypt or pbkdf2 can require a second or more per password hashing attempt. The entropy of a password becomes infinitely less limiting to security when each hashing attempt takes longer than iterating over a dictionary! For extra points, you could probably hack up something to dissociate a password hash from the account on the server database side, so an attacker getting the database can't even specifically target a particular high-value user. There are JS libs out there for PBKDF2 and SCRYPT, and salts can be uniquely assigned trivially. Site owners can check passwords at sign-up time against a list of known passwords in bruteforce dictionaries. There are probably libraries to check and enforce decent passwords (as in, length and proportionate variability of character use, not stupid overcomplexity), and if not then they'd be fairly easy to hack up. All of which means this: the problem we have today isn't that passwords suck (although there is a minimum practical length you should enforce). It's that the people providing the password have no control over the security policy of the site owners, and site owners think password security is something you enforce on users (no vowels! Pray to Slaanesh whilst entering your passwords or face account deletion!) and that you can store plains or unsalted md5s on your syndicated hipster blogging platform and sleep untroubled. On Tue, 12 Nov 2013 11:00:01 -0500 David Vorick <david.vorick@gmail.com> wrote:

https://www.schneier.com/blog/archives/2013/06/a_really_good_a.html

The xkcd comic doesn't really apply anymore. Dictionary attacks have gotten to the point where they can crack 'momof3g8kids' and 'Coneyisland9/,'

and apparently have dictionaries breaking 100 million words. As password attacks get better and better at predicting human patterns (and hardware gets faster), you are going to need to completely generate your passwords at random in order to defend against dictionary attacks.

Which means the current password model is broken, as we all know it has been for a while. Why isn't there a stronger effort to replace it with something like a universal public key system?

On Tue, Nov 12, 2013 at 4:01 AM, rysiek <rysiek@hackerspace.pl> wrote:

...

Dnia poniedziałek, 11 listopada 2013 15:29:13 Kelly John Rose pisze:

...

The most useful strategy I've seen is to use multiple authentication methods or the "a few really hard passwords + random statement for each site."

Ie. you can probably memorize something like

lMB^9Pl!

so use that for the sites and then tack on something like

lMB^9Pl!Ilikeshopping123

Then the probability of actually cracking that password is low, and unless you are being specifically targeted, even if they got that password they wouldn't immediately be able to use it on other websites. It's easy to remember because that 8 digit code you'll type everywhere, and the ending is always something cognitively easy.

Oblig. XKCD: http://xkcd.com/936/

-- Pozdr rysiek

With an average of 5 important sites and 50 less important site per person, it requires people to *remember* 55 totally different 20 character passwords.

If you could be assured of client-side salted-JS-hashing of the password prior to submitting it to the server, then you could in principal use the same password everywhere. This used to be the norm, but SSL made it easier first to store plains, and for (as the security concerns of break-ins became apparent) to store server-generated hashes. Yet many, perhaps most, services don't do their job correctly on the server-side. If it were still done client-side, a savvy user could make sure hashing were done correctly, and salted appropriately.

The world needs to forget passwords as remote identification and move on to client certificates. Preferably, a separate client certificate for each site. It takes only a small browser plug in to make it easy.

Ideally yes we'd all use unique certs for everything, but then we'd be tied to our particular browsers. You could make this work with a well-implemented browser sync agent, but what about users of pathetic platforms that don't support trustworthy browsers (iPhone, Nokia)? -Cathal