This an interesting if dense approach to doing away with the password: https://www.grc.com/sqrl/sqrl.htm
a little more high level: http://www.sqrl.pl/ Basically use an app on your phone or desktop to confirm your unique identity using a cryptographic signature. One click login… No passwords (except to access the authentication app… :P ) One interesting thing to note about the implementation, they define a new scheme for links sqrl:// that then get registered for the authentication app… Interesting approach to define a custom scheme/register app to handle it which could be taken advantage in a lot of situations. —joshua On Nov 19, 2013, at 10:51 AM, Owen Densmore <o...@backspaces.net> wrote: > 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 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. >> >> 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
============================================================ 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
