Now that you mention it I do see a peacock almost ever time I go through Nambe.
Cody Smith On Tue, Nov 19, 2013 at 10:51 AM, Owen Densmore <[email protected]> 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 <[email protected]>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 <[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 >
============================================================ 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
