Ray, you'd have a far better take on passwords, and security of all sorts
than most of us, love your input on this.
So here's an observation:
Passwords are Dead. Just move along and we'll come back with a better
solution after the commercial.
Why?
1 - To be secure, you depend on the ISP to be secure. That's OK, but does
fail often.
2 - Apparently length of passwords is the high order bit for crackibility.
We humans dislike typing 20 character passwords, especially on our phones,
and its extremely likely to be miss-typed at least once, probability of
typo goes up with each keystroke.
3 - We are also instructed to have a different password for each login.
Humans simply cannot do that, they are limited. Thus they resort to a
formula like two phrases with a 3-4 character difference in the middle,
with some significance like "azn" or "books" for amazon.
4 - Most ISPs have their own rules for passwords, and likely any formula
will fail on a percentage of them. Thus a formula will only work part of
the time. Maybe there is a subset that most ISPs accept? I found UNM, and
my bank, for example, failed to accept a formula I tried.
5 - This leads to keepass, 1password etc to remember all your passwords for
you. Silly, but still appears reasonable. But they typically fail in
certain situations. Ex: they are designed for browser use so are
plugins/bookmarklets. But what if you have a phone "app". Won't work. So
you have to do stupid tricks to go to the pw app and cut/paste.
6 - The latest trend to improve this is two-fold:
6.1: Reduce number of logins: Use OAuth to have just a few accounts
that are very secure. As soon as twitter, google, facebook, moz, yahoo,
... and the rest of the "standard ISPs" all have OAuth (or equivalent), and
are used by the vast majority of the other sites (forums, stores, ..) we
have reduced the complexity of the user. Probably will work with all
non-creditcard sites.
6.2: 2-factor: How make more secure? So far 2-factor works out pretty
well. It would require a standard pin generator, google's is pretty
effective. Have to do this to reduce the pile of silly physical pin
generators.
I'm not sure this will work, its too complicated for most people. We might
be able to have a single pin dongle for 2-factor, could help. Thus far
2-factor for me has been the best, and I use that account via OAuth for all
the forums, mail lists etc that accept that. Even stores as long as they
don't keep the credit card info.
The fallback is a password keeper as mentioned above. But do you really
want it to keep all your passwords? You're dead without it (travel etc)
and it simply doesn't work in all situations (apps vs browser) and its a
bit creepy to depend on a computer program for all your security.
Sigh.
-- Owen
On Mon, Nov 18, 2013 at 5:16 PM, Parks, Raymond <[email protected]> wrote:
>
>> The addition of a salt to a password makes rainbow tables much less
>> effective because it makes the table space larger, even trading off chain
>> length for convergence. However, rainbow tables are no longer the thing -
>> with multi-GPU setups, password crackers just brute force passwords.
>> Basically, the sequence is:
>>
>> 1. Using a large (20 million word) multiple language (but standard ASCII)
>> dictionary derived from text sources across the WWW, hash the words in that
>> dictionary with variants (leet-speak, other substitutions, plurals, added
>> numbers, 8 for "ate", et cetera), and compare the outputs to the captured
>> password file. Salt is basically a variant that can be accounted for -
>> extra random characters.
>>
>> 2. If some passwords are of the type you dislike, then those can be
>> brute-forced almost as fast as rainbow tables can be calculated. Salt is
>> irrelevant in this process, other than making the effective number of bytes
>> longer.
>>
>> In the Ars articles, Step 1 seems to get as much as 90% of self-chosen
>> passwords in a matter of hours. The practitioners in the Ars articles
>> don't go on to Step 2, but I would expect that to take less than a week.
>> If the hash algorithm is captured along with the passwords, then the
>> cracker has the advantage of knowing whether the web-site uses salt.
>> Operating systems, of course, are studied off-line to determine the
>> algorithm and use of salt.
>>
>> Ray Parks
>> Consilient Heuristician/IDART Program Manager
>> V: 505-844-4024 M: 505-238-9359 P: 505-951-6084
>> NIPR: [email protected]
>> SIPR: [email protected] (send NIPR reminder)
>> JWICS: [email protected] (send NIPR reminder)
>>
>>
>>
>> On Nov 18, 2013, at 11:48 AM, cody dooderson wrote:
>>
>> I find passwords really hard to remember. Especially those sites that
>> require numbers, symbols,uppercase, and lower case characters. I personally
>> would rather use a 20 character all lowercase
>> password<http://preshing.com/20110811/xkcd-password-generator/>than an 8
>> character mixed symbol password. As a result keep a document, in
>> the cloud, with all of my passwords stored in plain text. Many of these
>> passwords I could care less if someone cracked.
>> Also, I was under the impression that salting prevents the use of rainbow
>> tables <https://www.freerainbowtables.com/>.
>>
>> Cody Smith
>>
>>
>> On Mon, Nov 18, 2013 at 11:28 AM, Parks, Raymond <[email protected]>wrote:
>>
>>> WRT password cracking - Dan Goodin has a good series of articles on
>>> password cracking at Ars Technica.
>>>
>>> http://arstechnica.com/security/2013/03/how-i-became-a-password-cracker/
>>>
>>> http://arstechnica.com/security/2013/05/how-crackers-make-minced-meat-out-of-your-passwords/
>>>
>>> http://arstechnica.com/security/2013/10/how-the-bible-and-youtube-are-fueling-the-next-frontier-of-password-cracking/
>>>
>>> TL;DR - Current GPU-based password cracking using 20-million word
>>> dictionaries make truly random passwords below 14 characters and nearl all
>>> pass-phrases susceptible to cracking in a relatively short time.
>>>
>>> On a related subject, roughly 75% of websites store passwords as nothing
>>> more complicated than simple, unsalted MD5 hashes. This is almost as easy
>>> to break as as NTLM.
>>>
>>> Salt makes the initial crack more difficult, but if the same salt is
>>> used for all hashes, then subsequent cracks ignore it.
>>>
>>> WRT the use of PII - it's sold on various markets, correlated in a "big
>>> data" manner with other exposures, and, if enough information is available
>>> and the person's credit score is high enough, is used for credit attacks.
>>> In some cases, if banking information is correlated, the collection is
>>> used for banking attacks. If there is poor correlation but an email or
>>> FQDN is in the information, then the data may be used as a target list.
>>>
>>> Ray Parks
>>> Consilient Heuristician/IDART Program Manager
>>> V: 505-844-4024 M: 505-238-9359 P: 505-951-6084
>>> NIPR: [email protected]
>>> SIPR: [email protected] (send NIPR reminder)
>>> JWICS: [email protected] (send NIPR reminder)
>>>
>>>
>>>
>>> On Nov 18, 2013, at 10:12 AM, Owen Densmore wrote:
>>>
>>> A forum I belong to has been hacked, including personal info as well as
>>> passwords.
>>>
>>> How do they use this information?
>>>
>>> I presume they try the hash function on all combinations of possible
>>> passwords. (Naturally optimized for faster convergence). They see a
>>> match, i.e. a letter combination resulting in the given hash of the
>>> password.
>>>
>>> If they crack one password, does that make cracking the rest any easier?
>>>
>>> And does "salt" simply increase the difficulty, and indeed can it be
>>> deduced, as above, by cracking a single password?
>>>
>>> .. or is it all quite different from this!
>>>
>>> -- Owen
>>>
>>>
============================================================
FRIAM Applied Complexity Group listserv
Meets Fridays 9a-11:30 at cafe at St. John's College
to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
