As a quick followup: - I use 1password. Why? To collect a list of my logins. Most of us do not know half of the logins we have! This lets me at least spend an afternoon updating all my passwords if I want to. 1P seems OK and works well in my ecology.
- I use 2-factor with google and their app. And if a site lets me login w/ OAuth, I try to use google. A few more ISPs are using 2-factor and if they are easy to use, I may try them too. Main issue is pin; most sms it to you but dongles abound and I think I'll avoid them. - Where possible I use pub/priv key crypto. My hosting service. My home computers, servers and NAS, ssh sites. I wish I could use it on my router, router attacks are on the rise. -- Owen On Tue, Nov 19, 2013 at 10:21 AM, Owen Densmore <o...@backspaces.net> wrote: > 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 <rcpa...@sandia.gov>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: rcpa...@sandia.gov >>> SIPR: rcpar...@sandia.doe.sgov.gov (send NIPR reminder) >>> JWICS: dopa...@doe.ic.gov (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 <rcpa...@sandia.gov>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: rcpa...@sandia.gov >>>> SIPR: rcpar...@sandia.doe.sgov.gov (send NIPR reminder) >>>> JWICS: dopa...@doe.ic.gov (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
