Password re-use is dangerous, right? So what about stopping it with password-sharing? Two comp-sci boffins have proposed that websites cooperate to block password re-use, even though they predict the idea will generate "contempt” among many end users, . Their expectation is founded on experience: Troy Hunt's HaveIBeenPwned is useful because so many people reuse passwords, and it currently claims to record more …
No. Just no. Did the researchers think about what will happen if say SiteA is breeched? I read what they said but supposedly most sites only keep a hashed version of the password, yet we see email addies and passwords being dumped on Hunt's site all the time. So obviously passwords aren't as secure as these guys think they are.
Take it a step further and inform each user of the number of other users with the same password as you. For the truly security conscious corporation they could inform you which users were sharing your password as an added incentive to have a strong unique password.
Why it is necessary for sites even to know what the user passwords are?
Why do they store the password and not just its hash? That's just asking for trouble, i.e. screwing all their customers at the same time, as someone can steal the file containing all the passwords.
But maybe there is some psychological profiling data to be extracted from people's password choices and monetised.
This post has been deleted by its author
I have never, ever been able to understand why any organism higher up the evolutionary tree than a prawn would ever have thought of having the same password for every website was even close to being anything less than an absolutely barking mad idea.
I've got another idea - why don't we give all doors the same lock and key? What could possibly...?
"I have never, ever been able to understand why any organism higher up the evolutionary tree than a prawn would ever have thought of having the same password for every website was even close to being anything less than an absolutely barking mad idea."
A different identity and email address on two or more sites means using the same password at those sites is no more a security risk than using the same identity with different passwords. Only you know those accounts belong to the same person. If the identities can't be linked, then neither can the re-used password.
"I have never, ever been able to understand why any organism higher up the evolutionary tree than a prawn would ever have thought of having the same password for every website was even close to being anything less than an absolutely barking mad idea."
Most simple folk who have no idea about IT simply don't understand what goes on behind the scenes, really. They can understand using a password to logon to a PC or device and they figure out that no-one will try enough times to guess their password to be able to logon.
They then take that same simplisitc yet not unrealistic approach into a completely different world of cyberspace of which they have no clue, but assume it's similar, and assume that you IT professionals are doing such a good job that you are protecting their password - exactly the same as they trust their bank not to lose their money, same as they trust their accountant or lawyer to give them the right advise.
Are their assumptions unreasonable? Not really. Naive or lacking knowledge, definitely yes. But it's unfair to say they have not evolved beyond prawns, that's just a nasty, arrogant comment. As I said, the IT industry has an awful lot to answer for, and it starts with the likes of MS taking ownership and accountability for their crap code, but not just them, so many others. It's a complete mess out there and blaming the user and their poor passwords is the easy way out but will not fix the problems.
"I've got another idea - why don't we give all doors the same lock and key? What could possibly...?"
What you've described is having all doors in the world having the same lock and key.
The issue here is analogous to having all of of *your* doors having the same lock and key. Which is not that far removed from having one bunch of keys on you that let you access anything you own, which is what many of us actually do day-to-day.
@JohnFen wrote:
"Done correctly, no passwords are being shared. They'd be sharing password hashes instead"
Done "correctly" the hashes would be all completely different, on different sites, even for the SAME password, even different for the SAME password used for another, account on the SAME site.
If you change your password for the SAME password, (assuming this was allowed) the resultic data again should then appear completely different.
They should be using stored per login stored random salts, preferably long ones of 64 bits minimum, and at least 128 bits in my opinion, with iterative hashing, with a minimum number of iterations, the number of extra iterations being somehow controlled by the user's salt data and/or some other data. They could also perhaps add a site-wide salt (or pepper) to differentiated the site from others.
The hash itself, should therefore be completely randomized and without running through the algorithm with its stored data AND the password it should be impossible to tell otherwise if any particular passwords match anything used on other sites.
If they shared any other data with other sites to compare passwords used on those other sites, then that too would be grossly insecure and I would be very angry indeed with them.
To me the fact that they think they could do this, says much about their own (in)security,
Personally I wouldn't store hashes at all. It would be something different, but require hashing of course.
But just storing the raw output from a known hash algorithm is completely dumb to say the least
Shaun.
Different companies will use different methods to encrypt a password (& ilikely one way i.e. be unable to decrypt it). So any "hashed" data would have to be in a known, unencryptable format and so slightly better than passing raw password around, but still open to attack
So obviously passwords aren't as secure as these guys think they are.
I think you meant to say "password storage and handling by websites isn't as secure as these guys think they are".
Which is the conclusion they should have reached, given all the password lists on Troy's site originate from the very websites he is proposing should implement this fancy scheme...
Some stuff really needs security, some not so much.
I'm retired and now, and only have 4 mail accounts - Three of them are for different levels of "I don't care"; going from total crap (Gmail) through an old Hotmail account, up to an old ISP's $20/year one. Google seems to do a reasonable job of filtering crap, MS less so; and the ISP is really only used as the security account for Gmail and Hotmail and a few websites (about 6). The only one I really care about has a pwd of 13 chars, which I have had for at least 12 years, and funnily enough does not seem to have ever been compromised, and does not see any spam. I also have a Facebook account which I log into occasionally with no details other than my name, it has no "friends" either, but seems to occasionally generate crap.
I do not use Gmail, etc., to log into other accounts; and use a password generator which seems to work well - If I lose the pwd on these I really don't care as I could just generate a new account or use the recovery through the ISP. I have not put my real "Mother's Name", etc., anywhere and seem to have few problems.
A retired friend who used to be contractor to various banks thought I was paranoid (I am), but was recently compromised with a planted key logger. I suspect that he was deliberately spearfished through a Windows machine, I believe he now uses an iPad for anything important...
... there's a lot of bollocks talked about passwords.
My bank, and my main email account, are both pretty important to me. On those, I use strong passwords that are not reused from anywhere else. If I thought for one moment that my bank or my email provider was broadcasting my password, however encrypted, to every other internet service in the world, I'd close the accounts faster than you can say "formal complaint". I would deeply resent the idea that my bank had even tried to identify my email username, let alone password, or vice versa.
At the other end of the scale, there's dozens of tinpot little blogs (El Reg, I'm looking at you) that require me to log into something to post on them, and don't allow OAuth because... I dunno, they want to sell password managers or something. On those I see no reason not to reuse passwords, and I'll deeply resent anyone who tries to prevent me from doing so.
So this proposal is calculated to piss me off in two entirely separate ways.
> At the other end of the scale, there's dozens of tinpot little blogs (El Reg, I'm looking at you) that require me to log into something to post on them, and don't allow OAuth because
Conversely though, if El Reg ever went "sod local logins, you can log in with Facebook, Google or Twitter and no other way" that'd piss me off.
Nice to have as an option for those who want it, but an increasing number of sites (and apps particularly) seem to be making it the only way. Call me paranoid but I don't want the big providers tracking me around the net. You can block 'like' buttons etc reasonably well and easily, but it becomes an issue if you want to actually login somewhere.
I'd rather have a throwaway'ish password for El Reg than use any of the common OAuth mechanisms.
I agree. This is the most bonkers suggestion I've read about passwords ever. Second worse is to change a password regularly.
Indeed. I thought we'd finally managed to agree that making password systems more obstructive to users just results in weaker passwords being chosen. I guess the University of Carolina didn't get the memo.
I own the domain name I use for email and give a different address to each service/site I sign up for. I also use a different password of varying strength depending on the type of site it is. I realise that this won't be a solution for everyone but it does work for me.
I have elderly relatives who use the same password on various websites and despite my imploring say it's not a problem for them. One of them uses the GWR website who they asked everyone to change their password recently. My relative didn't bother doing so and then called me to say that they couldn't book train tickets. I said they had to change the password via the link they were emailed otherwise they couldn't. The amount of grumbling that produced was amazing. I've suggested possible solutions but "It's just easier to use the same one"
As the go-to techie for most family, friends and colleagues, it's certainly frustrating when you're asked what to do, spend your own time researching the best advice for that particular person's abilities and idiosynracies, and then be told that they don't want to do it that way. WHY DID YOU EVEN ASK ME??? I've found a method that's easier AND better for you, collected all the hardware and software, and written full instructions - if I knew you were going to ignore it, I could have spent the time rewatching my Monty Python DVDs...
Maybe users should just shutdown a few of their accounts. How many Emerdata / Palantir's need to occur before users realize - They're just marks, is a sea of data-sniping. The answer is lots actually. See here:
https://www.bbc.co.uk/news/world-us-canada-44023381
"Most Facebook users in the US remain loyal, despite the recent data sharing scandal involving a political consultancy firm, a poll suggests. Facebook had been lucky the data was apparently used only for political adverts and not anything more sinister. "I have yet to read an article that says a single person has been harmed by the breach,"
Even as news goes, that's a bit depressing. How can people make assumptions about how sinister things will get. Their data has only relatively recently been leaked in the Wild. Whereas Data-Mining is always evolving... Do Americans suffer from Dunning–Kruger effect? Or is it the US MSM mushrooming the population and controlling the narrative so tightly, awareness of Instagram / WhatsApp owned by Facebook just gets ignored?
~
https://www.bloomberg.com/news/features/2018-04-10/instagram-looks-like-facebook-s-best-hope
~
"Most Americans don’t know the identity of Instagram’s parent, which is just fine with Facebook"
mmm, what does "loyal" mean, though? It can run the gamut from "slavering defense if Zuck commits murder" through to "forced to keep my login so I can check a work-related page once a month". Anybody who is loyal, in the traditional sense of the word, to a multinational corporation that couldn't care less about individual users, is stupider than the average bear.
These research papers always seem to be pointing me in the direction of buying a solution. I like my solution better. I don't have different passwords for each site. I have different credentials. The credentials are associated with the site. The e-mail account for registration is associated with the site. The "Security Question" answers are always the same regardless of the question. All I have to do is remember the base for generating the credentials and presto I am in... I never supply my "proper" name and only supply a phone number when absolutely necessary for deliveries.
My Banking and important e-mail accounts have their own strong passwords that are never shared.
The "Security Question" answers are always the same regardless of the question.
I have toyed with the idea of making all my answers "Pork!", inspired by the famous Secret Policeman's Ball sketch.**
**Spoof of schoolkid quiz shows in which John Cleese (for it is he) asks a bunch of fellow satirists in school uniforms (John Bird, may he rest in peace, is especially good) questions from a list that got sabotaged.
What £$%^ arrogant!
To reduce the prevalence of password re-use, reduce the NEED for sodding passwords. Stop bullying users and start bullying the websites that demand users create an account for every inconsequential function.
Users are not an unlimited resource for you to do with as you please. Users are your paymasters. Stop making life more difficult with ever more convoluted complicated bloatware and start making the technology easier to use. Or is that not glamorous enough for you?
It used to be that most sites would have a "continue without registering" option (even if it was a tiny link you could easily miss), but that seems to have fallen out of fashion.
Like you, I just move on to another, or if no other choice, setup the account with the bare minimum info possible (an incorrect info for anything that's inconsequential to the order). Once the order's arrived, I'll either use "Delete my account" (if present), or edit out the real data, set a stupidly strong password and not record it.
The real data might still live in a backup, or revision history somewhere, but that's at least lower risk than leaving them with the correct details.
A recently introduced "encrypted mail" scheme I have seen sends, not an e-mail, but a link to the encrypted e-mail company's site, where you register and log in to see the e-mail.
Strike 1: it's a PITA.
Strike 2: Guess these guys didn't notice that there's a lot of spear-phishing going on, not to mention the fact that e-mail security teams take a dim view of such messages.
"A recently introduced "encrypted mail" scheme I have seen sends, not an e-mail, but a link to the encrypted e-mail company's site, where you register and log in to see the e-mail."
That's how our "e-payslip" system works. Yes, we are a tech company and people higher up still put "e-" at the front of words because it's what the "cool kids" do, yeah?
It used to be that most sites would have a "continue without registering" option (even if it was a tiny link you could easily miss), but that seems to have fallen out of fashion.
By the simple act of ordering you are "creating an account," insofar as your personal info will be thenceforth be in the possession of the seller, and the details of your purchase will be associated with you by name.
In practical terms, what then is the difference between registering and guest checkout?
"In practical terms, what then is the difference between registering and guest checkout?"
Probably some nuance of data protection laws. Personal data must only be held for the defined reasons and for as long as necessary. "Guest" ordering, by definition, means you are not planning a long term business relationship with the company. If you register, then you must take action to close the account so the data can then age and expire.
This would undoubtedly save the hackers some much time. So would no longer need to try to hack different sites, as they would now have a single site against which they could throw endless rainbow attacks from one of their botnets.
Example First off a slew of passwords for Facebook. Even though the password was wrong for facebook, the Password Similitude engine (sic) would allow them to know that it was the good password for another site because it would also be interesting X other sites..
It a theory looking for a buyout..
I agree this hasn't been thought through. Firstly, it assumes there is a trust relationship between unrelated websites and secondly, I suspect it will be difficult to protect this backdoor API from dictionary & password cracker attacks - I suspect this could be more remunerative than BitCoin mining...
Skype's slurping up dates of birth too - forced me to enter before I could load the client the other day.
My guess was that one was more to do with GDPR and what they can do with your data, so obviously I told Skype I'm 9 years old.
> Twitter is currently collecting the mobile phone numbers of it's users. How safe is that info with them? They're not allowing any accounts without phone numbers, so sod 'em.
They prompted me a while back to enter my mobile number to prove I wasn't a bot. So while I was in Tesco's I picked up a PAYG SIM and gave them that number. Once in, I deleted it back off my profile. It'll only ever go in a phone when I need to "verify" myself.
At first it felt a bit overly paranoid, but actually - they're insisting on my number (which they don't need on a routine basis) and asking me to trust them not to lose or misuse it. Once it's out, it's out, so why would you give them your regular number?
They prompted me a while back to enter my mobile number to prove I wasn't a bot. So while I was in Tesco's I picked up a PAYG SIM and gave them that number. Once in, I deleted it back off my profile. It'll only ever go in a phone when I need to "verify" myself.
When I last topped up I was given two free sims by the store manager. I use them for that purpose too.
Although they state in their second sentence of the abstract that their idea is bollocks:
‘Though the design of such a framework is fraught with risks to users' security and privacy’
they decide to proceed regardless.
I see great potential in further screwups of processor design. Maybe ‘optimizing’ virtualization. Why not have global inode ref counters for shared file systems...
The actual password should not be accessible for comparison with anything else, only with a salted hash of it.
The only way that e.g., Twitter and Facebook would know that two passwords were identical would be if they are using the same salt and an identical hashing technique.
I would guess that for the purposes of this, there'd be an agreed format for it to be stored in.
In fact, for this use-case, you probably wouldn't use a salted-hash in the way you would for credential storage - this stuff would only be triggered when a password is _set_ so you could afford to go for something a bit more expensive in processing terms. So, you'd probably generate a cryptographic signature using a shared/known key.
The problem is, with a globally shared key, you could _potentially_ still try and bruteforce signatures (the tables you generated would be applicable to every platform using the comparison service - essentially losing the benefit that a salt traditionally provides).
The alternative, as you say, is probably that services need to keep the password in some reversible format so that they can answer similarity requests. There are ways other than simply storing plaintext (or an encrypted version of, which is no better) but I don't know how strong they are against a determined analysis.
Password managers don't cover each use case. It's OK when they are on the same device, and they can automate input. But have you ever tried to use a really complex random password, one that's also hard to type, and have it shown on your mode while you try to input it into another device? It's uncomfortable enough you don't want to have to do it but seldom.
Also, with a password manage you become totally reliant on it. Just like mobe address book make you no longer remember telephone numbers, with password managers you don't remember password, so if you need access and for any reason the password manager is not available or not working, you're cut out.
"But have you ever tried to use a really complex random password, one that's also hard to type, and have it shown on your mode while you try to input it into another device? "
Yes, I do this every single day, since I use a password manager that is not connected with the machines I browse on. It's not that big of a deal.
"Also, with a password manage you become totally reliant on it."
All of my passwords are long, randomly generated strings that I change regularly. In practice, it's only a matter of a couple of days before my muscles have memorized the passwords that use on a daily basis, so I really only end up needing to look up more rarely used passwords.
I also keep an encrypted backup of those passwords, so should (for some reason) I am unable to use my password manager, I can still get access to my passwords. It's a bit of a hassle, but I won't get locked out (and I've never needed to use the backup in the years that I've been doing this).
There's your mistake. Choose an easy to type password instead. Make it longer so it's just as secure. You'll find you can type "balloon sausage monty pet dribble elephant noggin pleb" pretty quickly and it has around 100 bits of entropy.
(Or would do if you picked the words at random, rather than just making them up like I just did.)
Some of us can't remember passwords, I'm not the only veteran whose memory can't cope with such problems. I have two passwords, one made when passwords were first invented and another when every site started demanding 8 plus letters, numbers, caps, lower case, upper case and just to be safe a # + % or two. If my online password storage app. doesn't react to a password request then I'm stuffed.
I wish bright eyed, bushy tailed programmers would remember that the procedures that they write are also to be used by old, senile, handicapped, disabled amnesiacs.
And no I don't use internet banking facilities.
The problem I have encountered recently with e.g., Microsoft is that, if their password strength policy changes, they do not use the "grace login" principle to allow you to login once using the insecure password, then insist you change it before logging out.
My recent experience (mentioned in another thread here) is that the user is frozen out of their account and then forced to go through all sorts of hoops to establish their identify (Subjects of emails, passwords used before, people in your address book, etc.) before they give you that "grace login" opportunity.
"And no I don't use internet banking facilities."
Barclays bank in the UK requires four simple pieces of data for an HTTPS login.
1) your family name
2) an eight digit number that they originally sent you on a strong plastic card
3) the last four digits of the authentication debit card that changes about every three years
4) the "random" number from a little TFA keypad device they send you. To generate the number each time you need the above debit card and its four digit password - which you can change whenever you want at an ATM.
Not totally convinced that there aren't ways round some of those checks though.
Because the hashed value stored in the password field matches that from someone else.
Arguably, that is not good. The algorithm for password salting should include the username in the hashing process so that, even if everyone on that site used the same password, none of them would appear to be the same on inspection of the password field content.
However, if a hacker had access to the resultant password field, they could get valuable insight into the algorithm used for the hashing process by flooding the site with different usernames but identical passwords.
"The algorithm for password salting should include the username in the hashing process"
I would have thought that the time that the user created the account would be used then "user same login, same password" would be different across multiple sites and uname:pword-hash would be useless to hackers without the third part of the puzzle.
What granularity would be used for this third (temporal) part of the puzzle?
Arguably anything finer than "which date?" would be impracticable due to time zone imprecision. Even this could be problematic for someone creating a login on 31st December or 1st January in a Pacific location, which could potentially fail even a century comparison test.
Yeah, I've always preferred to have an independent per-user salt for that reason. Using the user-name opens you up to exactly the issue you suggested - password re-use on another site using the same mechanism will result in an identical hash.
The salt is just a randomly generated string stored alongside the user data in the user's table, one per user. People forget that a salt is not a secret, and treating it as such just leads to complexity in your code (which'll get unravelled soon enough). It's primary aim is to tip the cost/benefit balance of generating rainbow tables.
Site-wide salt = Generic rainbow tables don't apply, but for a high value target you could generate a set for the site. Likely better to fallback to hash bruteforcing unless you're planning on exfiltrating the users table regularly
Per-user salt = Generic and site specific RT's don't apply. Generating per user is possible, but time consuming, expensive (from a storage PoV) and not really worth the effort. Fall back to bruteforcing the hashes instead.
No part of either of those requires the salt to be secret. Making it secret might add a few hours fact-finding into the process, but that's nothing compared to the time & computing effort the presence of a salt has already added.
A site might know if two visitors to that site have the same password
Is this really a problem?
I fully get - from the analysis of previously released passwords that having too many accounts with the same password isn't good for security, but just what is "too many" - I suggest 2 users on Facebook say, having the same password isn't a big issue, you probably could have a few thousand with a sub 8-character password before security is degraded...
This post has been deleted by its author
I agree about being unusable.
But secure ? Why would you believe putting all your eggs in one unregulated basket is secure ?
If you use them only occasionally as a backup reference like the gentleman upthread, why use an application of unknown quality when you can merely encrypt a text file using some well-verified algorithm ?
I don't believe this ... "use a password manager"?
"Dear Password Security Thingy User. Your password is of great importance to us. This SuperSecurePasswordStorage App promises to never ever send your database of signins and passwords to a scummy server in out-of-reach-of-the-rozzers-land. In fact we're so confident in our scam ... err ... 'security' that we never even crossed our fingers or lied through our teeth when we wrote the app's privacy statement or generated to 130000 false-positive reviews ..."
Fundamentally there are a hundreds of password managers and no way of deciding whether they are any more secure than a post it note on the monitor ... In fact I would suggest that with the statistical incidence of burglary times the probability of a.n.other burglar being able to use the data on the post-it, the post-it would be more secure than a.n.other's NSA sponsored password app
Facebook have sent out an email about accepting their new privacy T&Cs by 25 May. Clicked on the link yesterday expecting to read the T&Cs - but instead it presented me with their login page.
I only login to Facebook on another PC reserved for that purpose as it is needed for a job I run. So I didn't do the login.
A while later Facebook sent me an email saying they noticed I was "having trouble logging in" - and offered a link that would be a "one click login" to my account. I am probably being paranoid for thinking they have just offered to breach my user security.
"I am probably being paranoid for thinking they have just offered to breach my user security."
Yes.
They also send a second factor via SMS even when you have registered a one-time password app.
So many ways to login, it's so hard to choose.
A bit like my old Ford truck, any old Ford key 1970's through 2000 will start it.
"A bit like my old Ford truck, any old Ford key 1970's through 2000 will start it."
That reminds me of a visit my family paid to relatives in another state. Looong time ago, in the 60's. We arrived, and they where not at home, so one of my parents, for reasons that I don't recall, tried our front door key in their backdoor, and it worked!
If a new <input> field type of "HashedPassword" was provider, the browser could hash whatever was submitted, salted by the domain name and username field contents (they'd have to be some parameter to give the id).
Each site would get a different value for the same password, but wouldn't necessarily have to do much extra work, except a flag to know if the user's password was created in this way (so subsequent logons will use it too).
The problem with doing that, though, is it introduces issues of it's own.
If the hashing mechanism for your "HashedPassword" standard turns out to be a bit collision prone (as they often do after years of use), then it doesn't matter what hashing mechanism (if any) is being used on the server as a brute forcer now has a weak point that can be targeted.
It also adds some complexity to the browser too, of course, but no-one seems to give a fuck about that anymore anyway :)
...that does not require password sharing.
Simply define a password hashing algorithm - say 'MINCE' which takes the standard password hashing algorithms and applies them all to the password, without a salt. E.g. apply a large multiple of rounds of argon2, bcrypt, Lyra2, and PBKDF2 serially. You take the resultant hash and store it in a common database, WITHOUT user id info. Whenever someone wants a new password, the same procedure is done, and you check if the same resultant hash has already been stored: if it has, you have pretty good evidence that the password you have chosen has been used by someone else, or by you on a different site.
As the database is simply hashes without user id info or salts, it can be shared, and you have a means of finding out whether the password you wish to use is globally unique or not, without compromising anyone's security.
It also means the site on which you have an account is free to use any, or none of the password hashing functions available, add salts etc. However, the security of this process would depend on there being no link between user-ids and the global hash - anyone who was able to make such a link would be able to run a dictionary attack against the hash.
When you've got the password available (so when they're setting a new password, or just after a login in the switchover period) you'd need to generate and store a representation of it in a format which could be used for this.
Hopefully no-one would be stupid enough to suggest plaintext or using reversible encryption, but there'd need to be some kind of shared format (I guess probably a cryptographic signature using publicly known keymatter, or some other derivation). You'd then use that for comparison whenever you receive a request to see if any of your users are using that password.
It does mean you'd essentially be storing a value derived from the password twice (your normal hashing mechanism + one of this) which could potentially open up some new and interesting brute-forcing tactics (attack the weaker of the two hashes, when you get a match, pass it through the stronger mechanism to see whether you got the actual password or just a collision - the latter is fine for logging into that service, but getting the actual password is more valuable if you want to try their password on other services)
Most of the things people protect with passwords aren't really all that important. It really isn't the end of the world if someone starts impersonating me on social media or any of the more niche sites I hang around. If you need your passwords to be different, just add a couple of letters to the same standard password to indicate which site it's for.
As for the servers where I am root (probably the most sensitive thing I have worth much protecting), they are accessed by ssh key from a limited range of IP addresses. There are about three buildings you could break into in order to gain access, and you'd have to use the computers you found there in situ rather than removing them to work on at your leisure. Uploading a new ssh key, opening another connection and clearing off in the time window before anyone noticed is perhaps just about feasible, but it would require you to know more detail than is in this message.
Anyway, h obody needs to share plaintext passwords when a salted hash is good enough for telling if or not a password matches another one. Keeping different hashes of the same password around is possibly a little bit risky, though, as it might give someone a toe-hold.
"It really isn't the end of the world if someone starts impersonating me on social media"
In the UK you can be prosecuted and even imprisoned for hate/terrorist postings on social media. Could be tricky - or at least very inconvenient - to prove it wasn't you that made the posting.
"the scheme would have to avoid imposing excessive overheads on authentication servers"
The scheme would only need to be used when a user creates a new account or changes a password. Once uniqueness of password has been determined it's business as usual; login password checks done against the local password list as it currently is.
I wouldn't object to a system shouting out "I have a hashed-user wanting to use hashed-password" and getting an answer back indicating how bad that would be. The repository doesn't need to store additional identity data or where the passwords are being used. It would seem trivial enough to implement.
My guess is that their reference to overloading auth servers probably relates to requests coming in from other services saying "hey, can you check if this password has been used?" rather than those going out as a result of a user changing their password on that service.
Which is a valid concern, imagine if you signed up you're relatively small site to it (for security, you understand) and then Facebook also joined and you had to handle a request whenever one of their users changed password (or created an account - including all the bots).
There are limits to how cheap you can make the processing too, so the only way you'd get around that, really, is to have some third party act as a middle-man for answering other's requests. Which means they'd need to hold a copy of your hashes, painting a big fat target on their backs and raising a number of other concerns.
Of course, at some point, someone will suggest sticking the hashes in a blockchain so that a network of nodes could handle the requests - they may even get rich/lots of funding off the idea, but it isn't necessarily a good idea for numerous reasons.
I just write the damn things down in "(random string)(clue)" format where the clue refers to some crap I've got memorised, which might be a password in itself, just an older one I can actually remember. Even if someone did manage to swipe the list they'd still not have any full passwords, just the part that's hard to commit to memory and immenently about to get changed because I know someone just swiped my list.
It's like book codes. If you don't know what book they're using that string of numbers is meaningless.
Even if they hash the passwords, let's not forget that recent MASSIVE cockup with windows authentication, where they were passing password hashes out to fake SMB sites, those sites were then using that data to identify the users passwords against rainbow tables.
However that aside, sites should not be sharing user data , becasue that would allow them to profile who has what services with whome.
yes, you can have a different password for every website that's made up with at least 20 characters including specials that would take so long to crack that for all intents makes it impossible.
but then you have to keep a list of those passwords and for security on a piece of paper in a locked safe.
its not very practical to use.....
so you start using the features of your browser to save your passwords. but that can be stolen by a hacker.
there are all the password wallet applications, but then if they get breached, well your screwed...
its all about how secure you need it to be against usability.
I am gulty of using the same passwords across different sites, but I have a method to that madness...
I have a relatively simple two word plus numbers, upper and lower case that I use for forums. The worst that can happen is that someone posts something under your name...
then there's shopping, they all get a unique password, but it is something that is easy to remember, they are all based on a single password, but the shop name will add a variant to to the password.
banking, now they get a completely unique password that will need to be copied and paste from a text file i keep on an encrypted memory stick. . with a long password I can remember. the password also gets changed once a month
its not perfect, but you have to have a balance between usability and security.
"The worst that can happen is that someone posts something under your name..."
I think that has already happened to you Anonymous Coward. I see heaps of posts under your name, many of them obviously not from you.
I'd get my coat, but I'm not sure which one it is, they all look the same.
How far are they going to go on this?
I can see that if implemented my passwords would probably end up as "F&*kYouFacebook", "F&*kYouTwitter", "F&*kYouSkype" etc.
Are they going to check that my proposed new password is not only different, but dissimilar to any other password used elsewhere?
Hmm. I remember something similar back in the 90s when computer security was usually an afterthought.
When changing my password, sometimes I'd be presented with the error "Your new password is too similar to your old password"
Which was a good sign they didn't know what they were doing - as if they were properly encrypting passwords, there'd be no way to even know what my old password WAS!
Dear onefang, it appears that your password on The Register is the same one as used by your account on Yahoo.
Really? Cool. It always annoyed me that someone else got a onefang account on Yahoo before I could, now I can claim it as my own. Bet it's full of spam though. And naughty photos of his/her/other butt ugly girl/boy/other friend. Probably also gets a monthly email from their mother asking why they haven't called.
Dear onefang, it appears that your password on The Register is the same one as used by your account on Yahoo.
i doubt that they would just check the password against a username, They would check it against a username and email combo, just to......
what the fuck am I talking about,,, this is facebook and pals... of course they will just check it against the username then tell you the password matches....
that said, I am almost certain google and facebook know exactly who I am without me even using a usename & password and could just log me in without having to enter a username and password...
1Password now checks your new passwords against the leaked passwords at https://haveibeenpwned.com/Passwords which probably contains all the common useless ones like qwerty etc. I think there are half a billion passwords there, maybe more now. Some websites also check against this list when new passwords are created. It’s also used by GCHQ. More good work by Troy Hunt.
>1Password now checks your new passwords against the leaked passwords at https://haveibeenpwned.com/Passwords
Only really of value if it gives a common usage rating, hence just because a 16-character password hash is on Troy's list against another (unrelated) user account, doesn't mean it is insecure, whereas if the password is in the top 100 or has had its hash cracked...
if the website were seriously trying to make people use unique strong password they would not allow the user to create their own password but generate them for the user.
I do know of a few websites that do this but your never going to get the big sites to do this because it makes logins more difficult unless you use a password manager to remember the passwords for you.
As long as you can trust the people you live with your passwords are probably safest written down and stored away somewhere safe.It is unlikely your average burglar will steal them during a break in, they looking for cash, jewellery and high value items, not books of passwords.
If your paranoid about having them written down, you could always add some extra letters/numbers on the end of the password which you know to remove when entering the password but someone who is reading your password book would not.
Well, the jokes on them--because I don't have any money in my account to steal, and with all my cards fully leveraged, I'm so over extended that nobody will open up a new line of credit!
If someone just wanted to impersonate me online, I'm sure my friends and family would appreciate the uptick in our interactions--and even if they're asking folks for money, I've already burnt those bridges too.
My photos aren't worth stealing either, because I've been with the same woman since before sexting was even a thing--so there's nothing marketable in there.
Yes folks, you can live with absolute security through obscurity--where the worst fate imaginable is dealing with the potential spoilers you might encounter if someone watching starts watching a few episodes ahead of you on Netflix. Or worse, browsing through a bunch of crap I'm not interested in, on my Amazon account, and/or setting up wishlist(s) that totally ruin any possibility of getting relevant suggestions--oh wait, never mind, my fiancee has already done a fine job of convincing Amazon that I'm into knitting, wearing women's clothing, and need supplies like luminol to help investigate crime scenes!
[Note: Amazon did suggest I purchase a set of lockpicks, with a clear practice lock a few years back--and that was probably the best $20 I ever spent.]
...and that would achieve the most important aim of the proposal, which is to force punters to use password managers that get in their faces and firmly insist on complex and fresh passwords for every online service...
...worry about the current increase in specialists anxious, not to advise us, but to FORCE us to behave as they would like us to?
In the UK you can no longer buy squash without artificial sweetener, because the companies have been forced to cut the sugar. The NHS discusses, and in some cases implements rationing of health care on the basis of BMI. There are many other examples.
There are names for people who are forced to do things against their will. And they are not 'free citizens'...
"...and that would achieve the most important aim of the proposal, which is to force punters to use password managers that get in their faces and firmly insist on complex and fresh passwords for every online service."
Yeah, brilliant, until the password manager is hacked, resulting in *all* of your accounts being breached.
It seems to me that they are using a "private membership test" protocol to check password reuse instead of "sharing passwords". And they encrypt passwords in a way such that ciphertexts are different for the same plaintext so brute-force doesn't work? Not sure. But personally, as a user, I don't like this proposal and don't expect me to change my mind.
I'm quite curious about how "password-sharing" works in their proposal. But I can't find anywhere in the paper mentioning "password-sharing". How on earth do they detect password reuse across different websites?? Does anyone know about "private membership test" stuff? It seems magic to me, in an unconvincing way.
Anyway, it sounds annoying but I don't reuse passwords.
>Password re-use is dangerous, right?
As a long time user of a password manager that flags where I have used the same username/password across websites, one of the things I've come across is how many 'websites' are actually amalgams of several websites ie. component parts/services are delivered by third-parties using websites on different domains, giving me the choice of whether I log in directly to a specific sub-website or go via the main portal website - in both cases my username/password are identical. Whilst this situation would seem to an be ideal candidate for a single-sign-on security solution, companies are clearly using the standard toolset.
No need, already done for you.
If you remember, for one, AVG's controversial previewing of all the links on the page currently being browsed (their reasoning being to see if it should pre-emptively warn the user of any problems). Such tactics effectively announce your upcoming visit to their website. AVG supposedly ditched that service after complaints, not just from users of their product, but also website owners for generating false visitor data.
I seem to remember getting a phone call from a company that had trawled through their logs and contacting me from that information. I had never expressed interest in their product and my only knowledge of them was my visit to their site. They freely admitted that their only knowledge of me was from my visit to their site.
Yeah, but 1) sites I've visited aren't the same as ones I have registered an account on and hence have a password for that needs checking and b) I use so many blockers/obfuscators/spoofers/fakers/etc. that I all but give up browsing any site ever again on a daily basis. It's worth it for the modicum of peace of mind it almost certainly doesn't merit but, by God, it's frustrating at times. On the plus side, the less I browse, the less I give away, so swings and roundabouts and my mileage may vary, I suppose.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
