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/
Related Stories
Computer security journalist Brian Krebs has posted in his blog that Reddit, a well-known social news aggravation site, has announced that an attacker compromised a several employee accounts at its cloud and source code hosting providers. The way in turned out to be Reddit's reliance on mobile text messages (SMS) in an imitation of two-factor authentication (2FA). Mobile application-based keys are an option. Hardware tokens would have also been reasonably secure instead but few sites do more than partially support them.
Reddit said the exposed data included internal source code as well as email addresses and obfuscated passwords for all Reddit users who registered accounts on the site prior to May 2007. The incident also exposed the email addresses of some users who had signed up to receive daily email digests of specific discussion threads.
Specific details of how the SMS messages were intercepted have not yet been made public.
Earlier on SN:
Google Defeats Employee Phishing With Physical Security Keys (2018)
SIM Hijacking as a Second Factor (2018)
Authentication Today: Moving Beyond Passwords (2018)
(Score: 5, Informative) by Apparition on Tuesday January 30 2018, @05:16AM (5 children)
As someone who has been the victim of credit card fraud five times, and victim of the Chinese government helping itself to my name, address, telephone number, Social Security number, fingerprints, and God only knows what else [wired.com], I have to say no thanks to biometrics. Biometrics may make a passable identifier to replace logins with, but passwords? No.
(Score: 2) by DannyB on Tuesday January 30 2018, @05:03PM (4 children)
If you use biometric for the ID (but not the password), and then require a conventional password*, you have 2-factor authentication.
There are only 3 factors to choose from:
1. Something you know. (eg, a PIN, Password, Unlock Pattern, Proper sequence of cat pictures, etc)
2. Something you have. (eg, ID Card, possibly with mag strip or chip, a house key, a fob or usb stick or device)
3. Something you are. (eg, fingerprint, retina scan, image of your face, semen sample1 )
Biometrics are okay as long as it isn't the only factor being used. Which has obvious security problems with images of your face, retina, or Mythbusters lifting fingerprints, etc. Not to mention the fact that you can't change your biometrics, or at least it is usually undesirable to do so.
-=-=-=-=-=-=-=-=-=-
1this limits the number of authentications done per day, and isn't sexist, no, not one bit
The lower I set my standards the more accomplishments I have.
(Score: 3, Informative) by darkfeline on Tuesday January 30 2018, @09:00PM (3 children)
No you don't. Your biometrics is public info, anyone can gather that information and replicate it.
I feel like that third factor is only thrown in there as a marketing ploy to push the rampant fingerprint authentication that is in every smartphone now.
"Something you are" is a horrible authentication factor. Almost all of it is public info by virtue of you existing, most of it can be trivially replicated, and worst of all you cannot replace it if it is compromised, which see first point.
Password and a key token. Done. Empirically shown to be very secure and relatively low inconvenience.
Join the SDF Public Access UNIX System today!
(Score: 3, Insightful) by DannyB on Tuesday January 30 2018, @09:24PM (2 children)
I am in agreement with the parent poster that biometrics are not a replacement for the other two factors. (He says the password.) But I'm okay with biometric in addition to other factors.
And your user name or user id (one of the typical fields along side password) is NOT one of the factors. Because anybody can know your user name / user id.
Biometric IS useful for certain applications. I find it incredibly useful to unlock my phone. It is my choice to enable that for my convenience. In this case, it is effectively "a button" to turn on the phone, but it only responds to my finger.
The lower I set my standards the more accomplishments I have.
(Score: 2) by darkfeline on Wednesday January 31 2018, @06:36PM (1 child)
Biometrics is not okay as an additional factor. Biometrics functionally can only play a role as an identifier, which as you say, is NOT a valid authentication factor. Because anybody can know and reproduce your fingerprint/face, etc.
>I find it incredibly useful to unlock my phone.
Naturally, because it is convenient, not secure. It is even more useful to not lock your phone at all and proportionally less secure.
Join the SDF Public Access UNIX System today!
(Score: 2) by DannyB on Wednesday January 31 2018, @08:04PM
Actually it is inconvenient to not lock your phone. Too often the phone gets activated in your pocket and then all sorts of havoc ensues. So on my previous phone I used an unlock pattern. I got so used to it that every single time I wanted to use my phone, I had to swipe the pattern. Then I got the fingerprint reader and all was wonderful.
I don't think of it as secure. If I really were after secure I would be using a real password. I find the fingerprint "button" convenient, because it is like going back to just having a simple unlock button that you press, but it is the fingerprint reader. A touch and the phone wakes.
The lower I set my standards the more accomplishments I have.
(Score: 0) by Anonymous Coward on Tuesday January 30 2018, @05:20AM (7 children)
But they don't get better security. The state just gets better tracking, of everything you do, everywhere you go, everything you buy. "Security" is bullshit. It certainly isn't for yours. And in fact, all this does is make fraud more convenient than trying to be honest. If my real credentials don't work, I just get some fake ones that will work better, and easier.
We have every right to demand convenience, and security. There is no reason to sacrifice one for the other. With sufficient demand we will get what we want. Unfortunately we have to do it together.
(Score: 5, Insightful) by maxwell demon on Tuesday January 30 2018, @06:12AM (5 children)
"We have every right to demand both eating our cake and having it. There is no reason to sacrifice one for the other."
Security is inconvenience. Even a simple password prompt is an inconvenience. You cannot get security without inconvenience.
Biometrics is convenience (no need to have to remember passwords), but at the cost of security (biometrics are not unbreakable, as has been frequently proved, and if your biometrics has been cracked, you cannot simply replace it).
Two-factor authentification is security, but at the cost of inconvenience (you have to carry around that second factor; if you use the phone as second factor, you get more convenience because you carry it around anyway, but at the same time less security because phones are greatly more hackable than dedicated authentication devices).
Password managers are a mixed bag. In principle, they don't give more security, as they just store passwords; theoretically you'd be more secure by storing those passwords in your head. In practice, they actually can increase security because our brain's ability to hold strong passwords is not very good (OTOH, a weak password on your password manager effectively weakens all passwords stored in it). The password managers on one hand increase convenience because you have to remember less passwords (just the one for your password manager), on the other hand decrease it because you always have to have your password manager around, and if you happen to forget your password manager's password, the shit really hit the fan.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 3, Informative) by anubi on Tuesday January 30 2018, @06:47AM (3 children)
My main beef with password managers is monoculture.
Once the encryption algorithm of *that* manager has been compromised, all the others are apt to be compromised as well.
Once the word is out how a "bump key" works, nearly all mechanical locks of that design are degraded as far as security goes.
Personally, I consider the lock as nothing more than evidence that I intended no access, and violation of my lock is only evidence that entry was gained without permission. I have other methods ( covert cameras ) to document the act so I can seek redress in a court of law.
Everybody has known for years that locking your car is no defense against a Slim Jim. I have even had to use that way myself a couple of times when I locked my keys in the car.
The thing that concerns me these days is how impersonal identity theft has become. All done by scripts. I never will know who is dinging me, and nearly every business demands my info with the quite legitimate reason that they need to vet me... problem is they keep sharing that information, willingly or accidentally, so that slowly but surely, everyone's private affairs get cross-referenced and indexed onto darkweb databases. Nothing is private anymore. I don't have anything that can't be replicated sufficiently to deceive a sensor so as to perform actions in my name.
The number one reason for my failure to accept even "micropayments" on the web is because in order to pay, even one cent, I have to reveal my payment credentials. I can trust NOBODY. Not even Equifax! They all *say* they can be trusted, but their fine print all says "if you actually believe what we told you in large print, you are a big trusting fool!".
I can't shut down everything, but I will avoid any kind of payment / identification for certain things, well known to be highly risky, such as porn, warez, pirated stuff, anything illegal, gambling, and games. I don't even have a google account yet. I use an anonymous email account, which I would pay for, if I knew beyond a shadow of a doubt, that they would not share my real info. I have researched through Spokeo and already there is far more stuff out there on me than I feel comfortable with. As a result of the Equifax breach, I know that there is enough out there to confuse the entire population of the world as to who is really who.
Its no longer a function of being careful.
Its now a function of pure statistics as to when my identity is going to be misused.
My best attempt to cope with this was to adopt a much lower lifestyle, so little is at risk. Own your stuff outright and pay cash when possible, using credit cards if necessary for telepurchases. Pay your debts off. If you have money laying around, keep it in some sort of investment which requires you to interface with your banker/broker. Personally. Something fishy come over the wire, and they will question it.
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
(Score: 2) by c0lo on Tuesday January 30 2018, @07:46AM (2 children)
Yes, but recall that joke with the guy donning his runners and telling his companion: 'i don't need to run faster than the lion, I only need to run faster than you'.
If a hacker targets you, it's only a matter of time before he gets your identity. If you are only one of the many, you only need to be a bit 'more secure' than the most of others.
True, given how many companies store data about you, you have little control on what/when the things go south. Minimising your profile involve indeed minimising the number of companies you share your data with.
Also, which devices you use to interact with them.
I'm using a single payment processor and that is linked with a debit card account which is loaded only minutes before making a purchase. If a webshop doesn't accept that payment processor, I don't buy from that shop.
And I do my online shopping and ebanking only from a laptop at home, laptop that runs Linux (thanks deity the era of IE-only supported is dead), laptop that never leaves my home and is powered off most of the time.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 2) by arslan on Wednesday January 31 2018, @12:59AM (1 child)
Eh? That analogy only stands for instance when the hacker is targeting individuals, not when they're targeting data dumps. The analogy to that would be you running faster than me is useless if there's a tsunami coming at all of us. I have to be running faster than that...
(Score: 2) by c0lo on Wednesday January 31 2018, @02:09AM
Works in this case too. Assuming your passwd is not based on dictionary words, the digest of it in the dump will be harder to crack. After getting enough passwords reversed, I have a feeling the attacker will just let yours be.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 0, Informative) by Anonymous Coward on Tuesday January 30 2018, @05:51PM
Security is inconvenience
That is a lie. It is supposed to be only inconvenient for the crook, not the user. We have to put the burden on the people who run the system. The problem is that we believe all their bullshit that "it's too hard". They are liars, and we have to call them on it and put them out of business if they don't provide what we demand. That is how we are supposed to work the "free markets". If we don't demand good service, we won't get it. The clarity is overwhelming.
(Score: 2) by DannyB on Tuesday January 30 2018, @05:19PM
Security vs Convenience.
Someone else already pointed out how these are a tradeoff.
I'll give an actual example.
I build a web application. People testing need to log in to it fifty times a day. So I built a feature where the server can be configured with pre-set credentials. When the login page is displayed, the name / password are pre-filled out with the configured values. This does NOT make those configured values valid. It just means you don't have to type them in. The server's configuration is only controllable by the server's owner. (And if not, then you've already got bigger problems.) It is still necessary to know credentials to put them into the config file. On test servers, these credentials don't provide access to anything but test data. Production servers are never configured this way. (And again, if an outsider knew valid credentials, and the config file could be manipulated by an outsider, then you've already got bigger problems.) There is also a compile time feature which determines if a compiled server even has this configuration feature available. Various development and testing features are controlled by compile time flags -- which the "About page" will indicate as flags in the version information so it is possible to detect a misconfiguration of the compilation stage of the build.
The feature has one more thing in addition to the name / password. It has an "autologin" flag. That way when testing, it is not necessary to visit the login page. Just accessing any bookmarked URL, which normally would route you through the login procedure first, ultimately gets you automagically logged in, and routed back to the bookmarked action you are testing.
This is an example of security versus convenience. I built a convenience that can be configured to bypass security, for internal porpoises.
The lower I set my standards the more accomplishments I have.
(Score: 5, Insightful) by Anonymous Coward on Tuesday January 30 2018, @05:32AM
Biometrics are a really really bad idea. I think we're all kind of influenced by the old sci-fi and thriller media where people login to things using retinal scans, voice checks, and other things. It seemed really cool and futuristic so naturally we want to go that way. In reality biometrics are like using the exact same password on every site you go to. Technology to spoof biometrics already exists and at that point literally every single device you've "secured" with it becomes broken. And unlike passwords, you can't simply change your biometrics.
(Score: 2) by The Mighty Buzzard on Tuesday January 30 2018, @05:50AM (5 children)
Bytes are bytes are bytes. It doesn't matter if you derive them from keystrokes or points on someone's finger or retina. The only things that matter are making the key as large as is practical and not using methods that make the bytes that make up the key be easy to brute force.
As for fingerprints, you leave them all over the place every single day. Follow anyone around for an hour and I can pretty much guarantee they'll leave ten clear prints for you to lift from the multitude of things they touch without thinking about it.
My rights don't end where your fear begins.
(Score: 3, Insightful) by c0lo on Tuesday January 30 2018, @07:52AM (4 children)
Oh, but it does.
If your retinal pattern is captured/duplicated in a way which can be used to fool a retinal scanner, good luck in performing a retinal reset.
Replace that value for any biometrics derived bytes.
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 0) by Anonymous Coward on Tuesday January 30 2018, @10:59AM (1 child)
Does anyone how reliable retina scans are in the case of a cataract or similar disease where the image of the retina gets less clearer?
(Score: 2) by DannyB on Tuesday January 30 2018, @09:28PM
I saw it on Star Trek: The Wrath of Kahn.
If the Federation uses it to protect the Genesis project data, then it must be reliable. I also seem to recall that Kirk's eyeball had a match of 99% out to some absurd number of decimal places then ending with a few non-nine decimal digits.
The lower I set my standards the more accomplishments I have.
(Score: 0) by Anonymous Coward on Tuesday January 30 2018, @04:50PM
(Score: 2) by arslan on Wednesday January 31 2018, @01:04AM
I have a replaceable glass eye you insensitive clod!
(Score: 3, Insightful) by Rosco P. Coltrane on Tuesday January 30 2018, @05:53AM
They're stored in your head - meaning:
1/ They're the only thing nobody can pry from you if you don't want to.
2/ They can be changed at will, unlike biometrics. If your biometric data are out in the open, it's game over. When your password is lost, you change it.
I'll keep my passwords thank you very much. All they require is a little bit of effort to remember them.
(Score: 2) by MichaelDavidCrawford on Tuesday January 30 2018, @06:29AM (4 children)
I once saw a movie in which the bad guy wanted to get into a restricted area so he removed on of the good guy's eyeballs then held it up to the camera on the end of a pencil.
Yes I Have No Bananas. [gofundme.com]
(Score: 2, Informative) by Anonymous Coward on Tuesday January 30 2018, @10:51AM
Demolition man: http://www.imdb.com/title/tt0106697/ [imdb.com]
You're welcome.
(Score: 2) by The Mighty Buzzard on Tuesday January 30 2018, @11:27AM (1 child)
Outstanding movie. One of the best action flicks of all time.
My rights don't end where your fear begins.
(Score: 2) by DannyB on Tuesday January 30 2018, @05:22PM
Please press 1 now if you would prefer an automated response.
The lower I set my standards the more accomplishments I have.
(Score: 0) by Anonymous Coward on Tuesday January 30 2018, @03:02PM
Plenty of other occurrences in fiction as well;
http://tvtropes.org/pmwiki/pmwiki.php/Main/BorrowedBiometricBypass [tvtropes.org]
(Score: 4, Insightful) by MichaelDavidCrawford on Tuesday January 30 2018, @06:31AM (30 children)
There is a certain class of website for which I've been using the very same password for twenty years.
If they require only what I regard as a sensible password I use the exact same one.
If they want what I regard as a paranoid password, I pull something out of my ass them request the change password link every time I log in.
I once had a spreadsheet with all my passwords on it but then I forgot the password to the encrypted disk image it was on.
Yes I Have No Bananas. [gofundme.com]
(Score: 2, Insightful) by Anonymous Coward on Tuesday January 30 2018, @06:43AM (29 children)
"elephant" here! I'm pretty much the same. The biggest problem is site A wants a six to eight character password while site B wants a ten to twelve character password. I have a "sensible" password, plus a paranoid one that adds a few bells and whistles (symbols). Then you get workplaces that make you change your password and keep a history so you can't use a previous one! fun...
(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.
The lower I set my standards the more accomplishments I have.
(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.
The lower I set my standards the more accomplishments I have.
(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.
The lower I set my standards the more accomplishments I have.
(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.
The lower I set my standards the more accomplishments I have.
(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.
The lower I set my standards the more accomplishments I have.
(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.
The lower I set my standards the more accomplishments I have.
(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"
(Score: 3, Informative) by c0lo on Tuesday January 30 2018, @01:47PM (2 children)
1. Have a password that you trust is good enough and has all the symbols/digits/caps etc.
2. each time you are required to change the password. form the new password from your trusted password to which you prepend/append the month-year of the change
Like 'welcome-2018jan' then 'june-welcome2018'
https://www.youtube.com/watch?v=aoFiw2jMy-0 https://soylentnews.org/~MichaelDavidCrawford
(Score: 0) by Anonymous Coward on Tuesday January 30 2018, @07:42PM
Sure! As long as I don't hit minimum or maximum character limits!
(Score: 2) by DannyB on Tuesday January 30 2018, @09:40PM
I use the most secure password there is.
It can be found here. [mostsecure.pw]
Everyone should be using this password.
The site gets an A rating on SSLLabs.com. [ssllabs.com]
The lower I set my standards the more accomplishments I have.
(Score: 2) by tibman on Tuesday January 30 2018, @07:29PM
Password expiration is dumb, imo. The only reason for it is if someone has already scooped your database and running attacks on the hashes. My work password is 30+ characters and expires every 3 months : ( Since it's a stupid windows environment you have to type in the stupid password 25 times a day. *grumble grumble* : P
SN won't survive on lurkers alone. Write comments.
(Score: 4, Insightful) by stretch611 on Tuesday January 30 2018, @08:06AM (2 children)
Biometrics are a good replacement for userids. They are horrible for passwords; they are too easy to fake, and impossible to alter even when compromised.
Multifactor sadly is questionable in most cases and more often than not used to get more personal information about you that companies do not need to know. Companies don't give a damn about your private information... they only want the cheapest "security theater [wikipedia.org]"
-- many ask for personal questions for authentication or password resets. However, many of these questions can be answered by anyone who can read your facebook or other social media. This makes them like a second password only worse because they are much easier to guess. Why try to crack a password when you can figure out the name of the person's hometown and reset their password for them?
-- (non)Random number generators, like SecurID and others are a good thought... However, a few years ago they were hacked making their devices useless. And that will always be the case... once the company providing it has the authentication for a good number of users, it becomes a prime target and it becomes a question of when, not if they will be hacked.
-- Steam and Gmail want to text you via your cell phone a "random" auth code. Personally, my game library is not worth the effort, and I would rather not give my cell phone out to every f-ing company in the world that I do business with. They have my home email... they can send the code there... just as valid and I can cut and paste the code which makes it easier for me than to type it. Especially if it is small type or uses 0/O, 1/l, S/5 or many of the other combinations that are hard to determine on a small screen or small font.
Password Managers are the best option... but only if you don't do it half-assed. LastPass(and others)... hell no... Any online password manager is only one hack away from you losing everything. And trust me, any server with that number of users and that many passwords is constantly under attack. Browser based storage is just as bad if not worse. Every modern browser is updated monthly with security fixes... Good that they are working on it, but it just proves how insecure they are.
I use KeePassX [keepassx.org]. Stored on a local drive. Requiring a 4096 byte key file AND a password. (Mine is over 15chars, with numbers, upper, lower, and symbols.) No chance in hell of me using any type of plugin to automate the process. A backup is stored on a flash drive and the key file separately.
Now with 5 covid vaccine shots/boosters altering my DNA :P
(Score: 1, Interesting) by Anonymous Coward on Tuesday January 30 2018, @01:20PM
Not even remotely, or at least not if you care about privacy. I like the ability to enter random, different userids on sites that I register on.
(Score: 2) by etherscythe on Tuesday January 30 2018, @07:12PM
This is exactly the reason I use Password Safe, by none other than Bruce Schneier himself. It's nice that there's an app that can paste as a keyboard replacement as well. The only inconvenience is in synchronizing my password database between desktop and phone. I understand there's also an app for that now.
"Fake News: anything reported outside of my own personally chosen echo chamber"
(Score: 0) by Anonymous Coward on Tuesday January 30 2018, @10:53AM (1 child)
Never really understood why OpenID didn't catch on... even for us techies you could setup your own service at home. Identify on your own system (with your own methods) and have access to any site that supports it.
(Score: 2) by janrinok on Tuesday January 30 2018, @03:03PM
I wonder if this is back to the 'convenience' problem again?
You and I might not have a problem with using OpenID but the average user doesn't seem to care too much about security, especially if one looks at how they use social media! Unless everything is set up when they purchase the device they don't seem interested.