SoylentNews is people
SoylentNews
from the isn't-it-about-time-to-move-on dept.
Submitted via IRC for TheMightyBuzzard
A global study from IBM Security examining consumer perspectives around digital identity and authentication today, found that people now prioritize security over convenience when logging into applications and devices.
Generational differences also emerged showing that younger adults are putting less care into traditional password hygiene, yet are more likely to use biometrics, multifactor authentication and password managers to improve their personal security.
With millennials quickly becoming the largest generation in today's workforce, these trends may impact how employers and technology companies provide access to devices and applications in the near future. Overall, respondents recognized the benefits of biometric technologies like fingerprint readers, facial scans and voice recognition, as threats to their digital identity continue to mount.
Source: https://www.helpnetsecurity.com/2018/01/29/authentication-today/
(Score: 1) by anubi on Tuesday January 30 2018, @07:02AM (24 children)
Personally, I wish they would hash the password strings... so I could enter literally anything of anything, maybe up to 4K bytes if I thought it prudent. By running an MD5 or similar hash on what I presented, they will be returned a fixed-length binary string that will be easy to store in their database. If anyone cracked their database... good luck. I know MD5 is broken... maybe another algorithm? I still use MD5 a lot in my stuff ( file integrity verification ), but it probably would not be prudent for mass market stuff.
Now, for me, on my side, I want to log into my bank... I might call up a local text file ( such as a copy of the Bible ), cut a piece of it, then paste it into the password window. My "password" is knowing where to go, and what to cut. Likely its a Bible verse meaningful to me, as I can go to any Bible site and get the exact same text for that particular version of the Bible should I find myself lacking my local copy. I might choose an entire chapter sans the first three words. That's a helluva lotta entropy.
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 2) by acid andy on Tuesday January 30 2018, @08:07AM (13 children)
The MD5 string is a fixed length, say, 16 bytes, so why would it be more "prudent" to use a 4K password? Surely beyond a certain point, adding length won't give you more security unless your password is using dictionary words making it more brute-forcible? I mean, you paste in your 4K string, it's hashed down to 16 bytes, but there must be other much shorter strings that would theoretically evaluate to the same hash. Or did I miss something somewhere?
Ah though if it's Bible verses (or other English text) you're pasting in I can see that the entropy would be limited if it was just 3 or 4 words compared to a whole chapter. You'd still have to paste it though unless you have a photographic memory and want to type away for ages, so why not a shorter, random string?
If a cat has kittens, does a rat have rittens, a bat bittens and a mat mittens?
(Score: 1) by anubi on Tuesday January 30 2018, @09:00AM (4 children)
I was thinking of something that was easy for ME to remember... I may remember a lengthy Bible verse much easier than even 16 bytes of something meaningless to me. And, to save typing, cut and paste. And longer, if I deliberately wanted to obfuscate, or it could be just one character.
If I wanted, I could make a "password generator" that predigests a "master password" into the MD5, and base all my "stored passwords" off of that, so even if my password generator was compromised, it has no idea of the "master password" that was digested first - still rendering someone with a lot of work to do. Nothing saying I can't send them my MD5, and they MD5 that again for their database.
I am trying to think of basing my encryption off of little things I know or can recreate.
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 2) by xorsyst on Tuesday January 30 2018, @09:44AM (1 child)
I think what you're after is basically supergenpass - it's a javascript applet / phone app that combines the site's domain name and a master password you specify, MD5s them, and generates a 10 character password for the site.
(Score: 1) by anubi on Tuesday January 30 2018, @10:00AM
Yes... that's the ticket!
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 2) by DannyB on Tuesday January 30 2018, @05:48PM
I remember (quotable aloud) Romans 6, 7, 8, 12. The book of Philippians (4 chapters), and the first 3 chapters of 1 John (letter, not gospel of). I also have encyclopedic knowledge of The Revelation. I can almost quote large passages of it. But I know the text and events described better than I know the Star Trek canon. (And I don't try to read anything into the text.) Then I happen to additionally know many other scattered verses here and there.
I would say that I have a fair amount of material I could use as password material, with a few digits and symbols sprinkled in.
You could also form passwords from meaningful combinations of words like David Bathsheba Uriiah.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 3, Informative) by pipedwho on Wednesday January 31 2018, @02:20AM
Using the Bible as your input dictionary to a simple function with an offset and length, the total search space is about 33 bits. There are about 785,000 words in the bible which are relatively unique if taken in blocks of at least 5 or 6 words. The total length of your 'snippet' is likely to want to be below about 10,000 words to avoid too much heavy duty copy and pasting from your external bible source.
So your offset and length taken together become the entropy input to your final password. So with about 19.6 bits + 13.3 bits of input choice, you have a brute forceable search space of around 33 bits if someone is actively attacking your password with the bible as a known dictionary source.
You could improve this by having a huge library of books that you also pick from. Say you pick randomly from 100,000 books at your disposal. That gives you another 16.6 bits of input. Now you're at 49+ bits. That's a bit better.
But, that's a lot of work to go through when for even better memorisable entropy you could just take 4 or 5 randomly selected words from a dictionary of 10,000 words and commit those to memory.
Oh yeah, I completely agree with the sites storing hashes instead of ridiculous password limitations and requirements. They should just require at least 8 characters of any type with no limits on length or content.
(Score: 3, Interesting) by DannyB on Tuesday January 30 2018, @05:34PM (7 children)
First, let's replace MD5 with something more modern. But 16 bytes is 128 bits of digest, and every bit is significant.
Regardless of which cryptographic hash algorithm, the point is that these algorithms are designed> so that it is computationally infeasible to ever discover any value that will hash to the same digest value.
Yes, there are infinitely many strings that will hash to the digest value of your password. But it is infeasible that you can ever discover one even with immense computational resources. And at least one cryptographic textbook suggests converting all of the non-solar mass in our solar system into computers organized in a sphere around the sun to make use of all of the energy. Even with such a data center, it would be infeasible. So I think you're safe from someone guessing anything that would ever hash to your 16 bytes (128 bits), or larger value on more modern hashes.
Changing 1 bit of your input password should generally affect approximately 50 % of the bits of the digest generated.
16 bytes or 128 bits means 2 ^ 128 which is 3.4 x 10^38.
A 256 bit hash (32 bytes) is even better. 2^256 = 1.157 x 10^77
The number of atoms in the entire universe is between 10^78 and 10^82.
A 512 bit hash has a number of potential digest values that vastly exceed the number of atoms in the universe by an inconceivable amount.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 0) by Anonymous Coward on Wednesday January 31 2018, @12:13AM (1 child)
Yeah, MD5 collisions are no longer "infeasible" to find: https://en.wikipedia.org/wiki/MD5#Collision_vulnerabilities [wikipedia.org] (fastest numbers I saw, said 11 hours on a "computer cluster")
(Score: 2) by DannyB on Wednesday January 31 2018, @02:36PM
The first sentence was let's replace MD5 with something more modern.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 2) by acid andy on Wednesday January 31 2018, @01:03PM (4 children)
While I found your post informative, I'm still not sure you've addressed what I was getting at: for any fixed length digest, there must be a maximum length of password beyond which adding more characters gives you no extra security, with the caveat that your password must contain sufficient entropy. Probably the upper limit would be the same entropy as a 128 bit string of random characters. Surely any more entropy than that in your password is just going to get thrown away when it's hashed down to 128 bits? It's the Pigeonhole Principle.
If a cat has kittens, does a rat have rittens, a bat bittens and a mat mittens?
(Score: 2) by DannyB on Wednesday January 31 2018, @02:47PM
That's an interesting idea.
Thinking about it, I suppose if I were to assume that any digest value is equally probable, then what you are really talking about is how easy is your password to guess.
Effectively saying: there must be a maximum length of password beyond which adding more characters doesn't make the password any more difficult to guess, maybe using a dictionary attack, that tries longer and longer variations of passwords with more words and symbols, digits, etc inserted. I'm not sure about that. If someone has to brute force your password length and variety definitely help expand the search space.
The assumption is that it is infeasible to generate any plaintext that will hash to the same digest of your password.
Maybe we should also add the distinction whether or not the attacker knows the digest of your password. For example, if the attacker has stolen the password table which gives him your user ID and password digest.
Attackers may spend months or years precomputing digests of all possible strings that are likely passwords. Every street name, city, state, county, country, nationality, books of the genre 4096 names for your new baby, every reasonable date written multiple ways. Then just do a database lookup to see if your digest is found, and look! I found it, the entry for password "12345" matches your digest!
To mitigate attacks where the attacker can obtain the password digest, both a salt and pepper are used. Generate two random values called salt and pepper. Take your plaintext password, prefix it with the salt, and suffix it with the pepper, so that you have a string which is:
x = salt + password + pepper
Now compute the SHA512 digest of X. In the database you must store the digest and the salt and the pepper. At login time, you recompute X and the digest of X. Then compare to the digest stored in the database. But to compute X, you need the salt and pepper which are also stored in the database. Now if the attacker has your digest, he also has the salt and pepper. But he can not possibly have pre-computed digests of many candidate passwords with your random salt and pepper. So that at least puts his brute force attack back to square zero.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 2) by DannyB on Wednesday January 31 2018, @02:53PM (2 children)
Oh, one other idea, and this is one I have implemented.
Use two different hash algorithms Hash1 and Hash2. Store two different digests in the database. At login time, the salt, pepper and plaintext password are hashed using Hash1 and Hash2 to produce two digests. Both digests must match.
Why?
Even if the attacker could produce some plaintext that combined with the salt and pepper would produce the digest1, they still have the problem of it not producing digest2 -- unless it really was your actual password (at least to an insanely high probability). There is probably not some plaintext value that will generate two matching digests using different hash algorithms unless it really is the original value.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 2) by acid andy on Wednesday January 31 2018, @03:41PM (1 child)
Although it sounds counter-intuitive, there must still be an infinite number of inputs that can produce at least some pairs of values of Hash1 and Hash2 otherwise you've just invented an infinite compression algorithm! I think, even if you set the requirement that the inputs must be plain text, that will still be true, otherwise you've invented an infinite compression algorithm for plain text!
Using two hashes certainly makes it more difficult both because you've added more bits and also it possibly spreads the risk of a weakness being discovered in one of the algorithms.
If a cat has kittens, does a rat have rittens, a bat bittens and a mat mittens?
(Score: 2) by DannyB on Wednesday January 31 2018, @05:45PM
Yes. As I said earlier there an infinite number of strings that produce the same digest. But the density of strings that produce both digests would be very low. So the probability of finding one would seem to be way, and I mean way way less, than what you would expect of just being able to find a string for a single digest.
To transfer files: right-click on file, pick Copy. Unplug mouse, plug mouse into other computer. Right-click, paste.
(Score: 2) by janrinok on Tuesday January 30 2018, @09:18AM (6 children)
I've taken this to the next stage. I have a file containing many megabytes of random data. I also have a python script that accepts my relatively simple passphrase, processes it to provide values for 'START' and 'LENGTH' and it returns the random string from the data based on the 2 values provided. It all lives on an encrypted drive, and I can use it for any number of different passphrases - even the name of the site that wants it e.g. 'www.amazon.fr'. If the site only accepts alphanumerics it can simply convert the random string by hashing or base64 encoding. CopyPasta and the job is done. Took me 15 minutes to write and works perfectly. The whole thing lives on my internal server and is accessible from anywhere on my cabled network - not a wifi connection in sight! If somebody hacks into that I have bigger problems than just losing my passwords.
The script is also is accessible from other machines on the network, and so can get the keys for encrypted drives etc, even at boot time.
Now such a program might be beyond the abilities of many, But anyone could have a copy of the program and provide their own source of 'random data' and the 'processing rules'. I wouldn't want everyone to know each others' processing rules.
Just make sure that you keep a copy of the program and the random data securely in several places. You don't want a single point of failure to negate all your passwords now, do you?
(Score: 1) by anubi on Tuesday January 30 2018, @09:58AM (2 children)
Cool!
My "file" is a copy of a particular version of the Bible, which I can access from nearly anywhere on the internet. Like you say, the main thing is keeping my "processing rules" to myself. With the same goal in mind you just stated... about having a single point of failure negate all my passwords, rendering them unrecoverable, even to me.
Ideally, I would like any password window to be able to accept the output of my MD5 digester. That way I can have different high-entropy passwords for everywhere. But to me, the password for, say here, would simply be "soylent". And the bank is simply "bank". Just something different so that the hashes I generate will be different. The real core of the thing is like you say, the processing rules "ruleset" is the heart of the security mechanism, which everyone makes for themselves.
One would have to code the thing themselves so that no automated script can be made to ferret out the critical heart and send it home.
Scripts correlate code easily to known patterns. Every instance of this thing has got to be unique.
Otherwise, the whole shebang becomes as fragile as monogenomic corn is to a deliberately engineered corn virus.
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 2) by janrinok on Tuesday January 30 2018, @02:28PM
I deliberately do not do this although I can understand the convenience that it would provide. I would rather cut and paste; the web page only has access to whatever I paste in the window. I could add a few more lines of code so that it is already in the buffer and a Ctrl-V is all that is required. It cannot discover where I get that data from or how it was generated, indeed I can change the location of the program freely as long as I know how to run it. At home, it isn't even running on the same machine that I use to access the internet.
For example, I have the same program, data and processing rules on a memory stick so that I can travel with it or use another computer other than my own. After I have removed the stick there is nothing on the host machine to compromise it. If the memory stick is lost, stolen or seized by LE it might compromise my random data and processing rules, but without knowing what 'key' I type in to access a specific password it is unlikely to produce the correct data for anyone else. And that is assuming that whoever finds it recognises what it is or what it might be used for.
If you use the output of MD5SUM someone already knows the length of your password and the valid character set, although that is certainly much more secure than a simple passphrase. However, I realise that many websites only accept a very limited character set anyway. I have also found a few sites that only look at the first n characters so any more than that is ignored. Any additional effort on our part will achieve nothing in terms of additional security. I don't tend to use those sites often as I seriously doubt their commitment to keeping my data safe.
(Score: 2) by janrinok on Tuesday January 30 2018, @02:55PM
Giving it a bit more thought, the rule set is nothing more than a sequence of numeric values in my program - how they are generated is the key - and the program knows how to interpret them. However, it would be easy for me to add an 'installation key' facility so that any key specified would automatically generate the rule set and a large random data file. The installation key would only be used once (it would be repeatable given the same key on subsequent installations) but would mean that anyone could install the program, choose an installation key, and be good to go with a unique set of random data and rules. Hiding the rules somewhere in the random data set would make them unrecoverable unless one knew where to look for them.
I might kick this idea around a bit but, for my current needs, it is not necessary.
(Score: 2) by sbgen on Tuesday January 30 2018, @03:34PM (2 children)
Do you have that script up some where? Asking for a friend....
Warning: Not a computer expert, but got to use it. Yes, my kind does exist.
(Score: 2) by janrinok on Tuesday January 30 2018, @03:56PM (1 child)
Its not on a site, and I'll have to rewrite parts of it. It wasn't designed for anyone else and my settings are currently 'hard-coded'. Let me do a bit of work on it and I will let people have it if they want to
laughuse it!(Score: 2) by sbgen on Tuesday January 30 2018, @06:44PM
Thanks, looking forward to it. Says my friend...
Warning: Not a computer expert, but got to use it. Yes, my kind does exist.
(Score: 2) by etherscythe on Tuesday January 30 2018, @07:04PM (2 children)
I had similar ideas, until I started running into logins that had MAXIMUM password lengths, and disallowed certain special characters. I am flabbergasted at the audacity of a bank to tell me that my password is too long, yet that is exactly the issue I have. And I have bigger problems with other banks, so it is not as simple as shopping around. Instead, I get to adjust my password policy fifty different ways for just as many websites, and then depend on not being the slowest gazelle in the herd.
"Fake News: anything reported outside of my own personally chosen echo chamber"
(Score: 0) by Anonymous Coward on Tuesday January 30 2018, @07:40PM (1 child)
The logins that have maximums generally have minimums. Plus odd rules. You get where this is going, right?
(Score: 2) by etherscythe on Wednesday January 31 2018, @06:32PM
No, I don't see where you're going with that. Let me hazard a wild guess:
They're trying to make passwords ridiculously difficult to manage because they want to implement an alternative system, like an implanted bio-chip, which they can use to track our every move and sell it to Joe Public as the salvation of his precious TV tropes intake time. And then all your souls are belong to them. Sound about right?
Mind you, I wouldn't put something of the sort past them - I've heard those sorts of noises made in an unironic, non-satirical manner. You've just given very few clues as to your meme du jour.
"Fake News: anything reported outside of my own personally chosen echo chamber"