GitHub Security Update: Reused Password Attack(github.com)
github.com
GitHub Security Update: Reused Password Attack
https://github.com/blog/2190-github-security-update-reused-password-attack
12 comments
Just a thought, but GitHub could be handling this proactively to ensure the security of their members given the sensitivity of private repositories:
Step 1: Grab LinkedIn breach data
Step 2: Compare email addresses/usernames from LinkedIn to GitHub
Step 3: Check if passwords are the same
Step 4: Reset password and notify if they matchStep 3 is not possible without one of the following;
GitHub keeps a copy of the password in plain-text
GitHub keeps a copy of the SHA1 hash of the password
GitHub cracks the SHA1 hash and checks against their hash
GitHub calculates the SHA1 hash of the password after a valid login
The LinkedIn dump is trivial to convert back into plain text. They're all SHA1 hashes and aren't salted. You can just download an SHA1 rainbow table[0] and instantly convert them to plain text.
[0] http://project-rainbowcrack.com/table.htm
[0] http://project-rainbowcrack.com/table.htm
Correct me if I'm wrong, but rainbow table is for popular password and character combinations yes? If my password is s0m3th1nggsup33rhard, you cant make out the string from the rainbow table.
Depends on the specific rainbow table.
The ones I linked to are brute force, every single SHA1 hash for all common ascii characters up to 8 digits long. You can also download smaller rainbow tables for common passwords, dictionaries, or similar.
Ultimately SHA1 is extremely fast to commute in 2016. So even if a rainbow table doesn't suit your needs, you can easily generate a new one which does, but likely you'll break a good chunk of passwords just using the "out of the box" 1-9 A-Za-z0-9 and specials rainbow tables.
The ones I linked to are brute force, every single SHA1 hash for all common ascii characters up to 8 digits long. You can also download smaller rainbow tables for common passwords, dictionaries, or similar.
Ultimately SHA1 is extremely fast to commute in 2016. So even if a rainbow table doesn't suit your needs, you can easily generate a new one which does, but likely you'll break a good chunk of passwords just using the "out of the box" 1-9 A-Za-z0-9 and specials rainbow tables.
You're wrong. It's not just a dictionary. While tables are generated with a cap on length and characters used that's not the same as being for popular passwords.
That's good and all, but, really: get a password manager and start using it. Nobody can afford to share passwords between services anymore.
Any password managers you would recommend?
Anyone looking right now is stuck with the paradox of choice[1], it's easy to look at the list and say for any given manager, "yeah but <x> says that one is rubbish" and end up picking none and just using ~/password.txt.
[1] http://uk.pcmag.com/password-managers-products/4296/guide/th...
Anyone looking right now is stuck with the paradox of choice[1], it's easy to look at the list and say for any given manager, "yeah but <x> says that one is rubbish" and end up picking none and just using ~/password.txt.
[1] http://uk.pcmag.com/password-managers-products/4296/guide/th...
Then at least 'gpg --encrypt ~/password.txt'.
I'm a fan of SuperGenPass[0], though you need to use the "mobile" version. The bookmarklet is insecure.
[0]: https://chriszarate.github.io/supergenpass/
[0]: https://chriszarate.github.io/supergenpass/
Your browser most likely already has one that is well inegrated. Doesn't solve the problem of sites that try to prevent it from working or non-web things, but covers most cases.
Well integrated? (Sure) Secure? (Maybe). Cross-browser? (Hell no!)
*of course I need multiple browsers; even in 2016, the Browser Wars are not over.
*of course I need multiple browsers; even in 2016, the Browser Wars are not over.
I knew I had already been "pwned" from adobe, but I just checked again and I was done in again from x-split.
I've since switched to using secure (60bit) passwords everywhere, but these are just the ones that have been made public, for every public release of info there are likely cases where the data has been kept privately.
Passwords suck, I wish everywhere had support for 2fa.
Here's a "did you know" about passwords: Did you know blizzard only uses the lower-case for passwords? You can enter any case of password and still match, so for blizzard always use a longer password because 'a' and 'A' are not unique.
I've since switched to using secure (60bit) passwords everywhere, but these are just the ones that have been made public, for every public release of info there are likely cases where the data has been kept privately.
Passwords suck, I wish everywhere had support for 2fa.
Here's a "did you know" about passwords: Did you know blizzard only uses the lower-case for passwords? You can enter any case of password and still match, so for blizzard always use a longer password because 'a' and 'A' are not unique.
I suggest 80+ bits to avoid getting caught by rainbow tables and similar batch attacks, which can get you in cases of password database dumps. 64 bit keys have already been cracked many times over in various distributed efforts.
If some site just uses plain MD5 then raw bruteforce might have already come across your password, or might do so anytime in the future.
If some site just uses plain MD5 then raw bruteforce might have already come across your password, or might do so anytime in the future.
The 60 bits refers to my passwords generated rather than password storage, where I would use something much stronger. (bcrypt or better!)
So for instance length 10 passwords each character from a list of 64 characters (the usual [a-zA-Z0-9] plus some special characters, minus confusable ones) is generated with 60 bits.
Increasing that to 12 characters gets to 72 bit, beyond that is hard to manage. Rainbow tables is about getting into an account from hashes, and doesn't typically actually resolve the actual password used, but something that instead hashes to the same thing. (In a rainbow attack you would hash H(X) then H(H(X)) then H(H(H(X))) etc, eventually for every hash you have something that hashes to that hash. Obviously this only works for small hash lengths and are what salts were designed to protect against.
But you're not hashing actual passwords, you're hashing the random results. When you're hashing passwords, those are dictionary attacks. If there's no salt or a weak (single-site-salt) salt then you can pre-hash a whole dictionary. Otherwise you have to hash a dictionary for each salt. But 60 random bits are unlikely to appear in any dictionary attack.
I'm not saying 60 bits of entropy in a password is enough to protect against a targeted attack, but it's enough to stop the password being found through a dictionary or cheap attack, which is all you can really protect for (you shouldn't re-use passwords anyway), the rest is up to the site operator to secure your password with hashing, at which point the salt has more entropy than your password anyway.
For a master password I'd obviously recommend going a lot stronger.
Ultimately, if a database has been completely owned, then you can't really protect against someone getting into that account, they could just do an "UPDATE users SET password=null" after all. So eliminate all password re-use, prevent your passwords being dictionary guessable, and secure your password list with a very strong master password.
So for instance length 10 passwords each character from a list of 64 characters (the usual [a-zA-Z0-9] plus some special characters, minus confusable ones) is generated with 60 bits.
Increasing that to 12 characters gets to 72 bit, beyond that is hard to manage. Rainbow tables is about getting into an account from hashes, and doesn't typically actually resolve the actual password used, but something that instead hashes to the same thing. (In a rainbow attack you would hash H(X) then H(H(X)) then H(H(H(X))) etc, eventually for every hash you have something that hashes to that hash. Obviously this only works for small hash lengths and are what salts were designed to protect against.
But you're not hashing actual passwords, you're hashing the random results. When you're hashing passwords, those are dictionary attacks. If there's no salt or a weak (single-site-salt) salt then you can pre-hash a whole dictionary. Otherwise you have to hash a dictionary for each salt. But 60 random bits are unlikely to appear in any dictionary attack.
I'm not saying 60 bits of entropy in a password is enough to protect against a targeted attack, but it's enough to stop the password being found through a dictionary or cheap attack, which is all you can really protect for (you shouldn't re-use passwords anyway), the rest is up to the site operator to secure your password with hashing, at which point the salt has more entropy than your password anyway.
For a master password I'd obviously recommend going a lot stronger.
Ultimately, if a database has been completely owned, then you can't really protect against someone getting into that account, they could just do an "UPDATE users SET password=null" after all. So eliminate all password re-use, prevent your passwords being dictionary guessable, and secure your password list with a very strong master password.
Regarding Blizzard passwords: an old acquaintance generated his own SHA-1 hashes for his Battle.net account - which did not resolve to characters which could be input by a regular client - so nobody else would be able to login to his account even if they had the information. Pretty neat.
How did he log in?
What the page doesn't tell me is: What is their definition of an "affected" account?
Obviously one where an attempt was made, and succeeded, would count as affected.
But would an account where an attempt was made, and failed, also count?
What if the userid and password are correct, but 2FA stopped the attack on an account. Is that account affected, in their view?
Obviously one where an attempt was made, and succeeded, would count as affected.
But would an account where an attempt was made, and failed, also count?
What if the userid and password are correct, but 2FA stopped the attack on an account. Is that account affected, in their view?
My guess is that all affected accounts are those that had multiple successful and/or unsuccessful login attempts coming from the same source.
> But would an account where an attempt was made, and failed, also count?
I wouldn't think so. There must be countless incorrect password attempts all the time.
> What if the userid and password are correct, but 2FA stopped the attack on an account. Is that account affected, in their view?
Interesting question. I'd hope they'd inform me if somebody had my password and was only blocked by 2FA.
I wouldn't think so. There must be countless incorrect password attempts all the time.
> What if the userid and password are correct, but 2FA stopped the attack on an account. Is that account affected, in their view?
Interesting question. I'd hope they'd inform me if somebody had my password and was only blocked by 2FA.
Wouldnt you have gotten unexpected 2fa notifications if that were the case?
This is true only if you use SMS for 2FA.
For either method, you can audit the activity of your account on the GitHub security page: https://github.com/settings/security. For example, upon having deliberately got my 2FA token wrong, "user.two_factor_requested" and "user.failed_login" events were logged for me.
For either method, you can audit the activity of your account on the GitHub security page: https://github.com/settings/security. For example, upon having deliberately got my 2FA token wrong, "user.two_factor_requested" and "user.failed_login" events were logged for me.
Interesting, I'd never checked that log before, and I just noticed a failed login (though no two_factor_requested) from an IP address in Brazil.
I'm gonna change my password just in case.
I'm gonna change my password just in case.
I feel like sites should somehow preemptively disable passwords that have leaked publically. Is there a simple way for them to do so without downloading every leak themself? Is there a simple way for whitehats to help out? Whitehat means you can't test the site without their permission, but someone could have a database that they provide partial access to for sites without leaking and spreading it further themself?
Here's an idea I just thought of: sites should have a standardized, secondary place to log in, where if the login is correct it automatically disables the password and requires a reset. "Report a compromised account", as it were. Anyone (or maybe specific whitehat groups) should have explicit permission to try any logins they want there: after all, if they succeed in logging in then the right thing happens and the account is locked. It's impossible to gain any illicit advantage from such access because any correct credentials are locked as soon as you try them. (Is this assumption robust?) So whitehats could then take lists and throw them against sites that implement this standard, but no attackers can gain from this.
The only problem I see is that disabling rate limits would open you to DOS (also if multiple people use the same list, although better coordination would help solve that): maybe allow bulk uploads which take less bandwidth overall.
Does this idea have any value?
Here's an idea I just thought of: sites should have a standardized, secondary place to log in, where if the login is correct it automatically disables the password and requires a reset. "Report a compromised account", as it were. Anyone (or maybe specific whitehat groups) should have explicit permission to try any logins they want there: after all, if they succeed in logging in then the right thing happens and the account is locked. It's impossible to gain any illicit advantage from such access because any correct credentials are locked as soon as you try them. (Is this assumption robust?) So whitehats could then take lists and throw them against sites that implement this standard, but no attackers can gain from this.
The only problem I see is that disabling rate limits would open you to DOS (also if multiple people use the same list, although better coordination would help solve that): maybe allow bulk uploads which take less bandwidth overall.
Does this idea have any value?
AWS did that for me. They sent an email saying that my AWS password was the same as one found in a breech, so they reset my password proactively.
"Hello,
At Amazon we take your security and privacy very seriously. As part of our routine monitoring, we discovered a list of email addresses and passwords posted online. While the list was not Amazon-related, we know that many customers reuse their passwords on multiple websites. Since we believe your email addresses and passwords were on the list, we have assigned a temporary password to your Amazon.com account out of an abundance of caution."
"Hello,
At Amazon we take your security and privacy very seriously. As part of our routine monitoring, we discovered a list of email addresses and passwords posted online. While the list was not Amazon-related, we know that many customers reuse their passwords on multiple websites. Since we believe your email addresses and passwords were on the list, we have assigned a temporary password to your Amazon.com account out of an abundance of caution."
have i been pwned has an API: https://haveibeenpwned.com/API/v2
Troy doesn't (for very good reasons) keep the passwords or hashes from breaches - just the email address. That make his API not quite capable of doing what's proposed here - Github can't use Troy's HIBP API to detect whether a breach containing my email address included a password that authenticates with them. (And I'm not sure there's even a way to make that service without creating _way_ more security problems than it solves...)
Do you see any blatant security problems with my proposal? The biggest problem besides DOS is that it leaks passwords to the site, which may prevent this from being useful except to trusted sites. But that can be solved by hashing/salting before uploading to the site, as long as the site publicizes their salting method (which shouldn't present security concerns, right?)
Doesn't help without passwords, which present some ethical problems with helping spread them especially from that site as he gets some dumps that aren't public.
With my idea the people with the data would be able to directly shut down the accounts ethically.
Maybe the proposal could also hash and salt the passwords before sending it to the site, which sounds even better for security and wouldn't be too much of a hassle for whitehats who want to help.
With my idea the people with the data would be able to directly shut down the accounts ethically.
Maybe the proposal could also hash and salt the passwords before sending it to the site, which sounds even better for security and wouldn't be too much of a hassle for whitehats who want to help.
What if one or many "leak" on purpose tons of passwords? We end up forcing people to use password managers (or post-it)?
If an adversary or potential adversary knows your password, there's a strong case to be made that it should be changed, at least for services that require strong security.
I don't quite get your concern. Isn't that better than them getting their account hacked?
I don't quite get your concern. Isn't that better than them getting their account hacked?
The password space is big. They could release trillions.
I hadn't noticed that Github started supporting U2F. Nice to finally use my keys for something other than Google accounts.
GitLab supports it as of a few days ago :)
So what happens if you lose the dongle?
I have YubiKey Nanos "permanently installed" in each computer I use, as well as a portable one. If I lose all my computers, and my keys, and my phone... I guess I'll have to make a new Github account. It's all open-source anyway!
You can add multiple keys, so you could have a primary one that's with you and another one that's stored somewhere safe. You can also configure OTP and/or SMS-based 2FA and backup/recovery codes as a fallback mechanism.
You use the customer support backdoor.
Dropbox does too! Unfortunately, those are the only sites supporting U2F I know of at the moment.
http://www.dongleauth.info/ maintains a list of sites supporting U2F devices. There aren't many yet, but it looks like a Wordpress plugin exists that may end up in core. There are also a handful of additional sites listed in issues and pull requests on the site's GitHub page (https://github.com/Nitrokey/dongleauth).
(I'm not affiliated with the site, I just check it periodically and thought it might be of use here.)
(I'm not affiliated with the site, I just check it periodically and thought it might be of use here.)
Bitbucket as well.
That's new! Took more tries than normal to register, but that's great. They took so long to roll out even TOTP based auth, I figured it would be ages before seeing U2F.
[deleted]
[deleted]
Google also supports U2F
For those of us who don't already know, this is U2F: https://www.yubico.com/about/background/fido/
I wish AWS would!
Why U2F is betthern than using an Authenticator?
Here's a brief comparison between OTP (Authenticator) and U2F: https://www.yubico.com/2016/02/otp-vs-u2f-strong-to-stronger...
One big advantage of U2P is protection against phishing and mitm attacks, which OTP is vulnerable to. There is more information here: https://developers.yubico.com/U2F/Protocol_details/Overview....
One big advantage of U2P is protection against phishing and mitm attacks, which OTP is vulnerable to. There is more information here: https://developers.yubico.com/U2F/Protocol_details/Overview....
U2F is immune against phishing.
I got an email from Bitbucket earlier today warning me about unusual behavior on my account as a result of reused credentials. Is it an attack across several version-control services?
I got a note over the weekend from Steam (steamguard) indicating that someone attempted to log into my account. They're hitting everything.
I got the same mail, seems like a coordinated attack. Luckily I had 2FA enabled, I'd recommend everyone to do that as well as it protects your account in these cases.
Bitbucket provides an audit log and a list of recent login sessions where you can see if your account has been accessed and if anything destructive was done to it. Github has a similar feature I think.
Bitbucket provides an audit log and a list of recent login sessions where you can see if your account has been accessed and if anything destructive was done to it. Github has a similar feature I think.
[deleted]
This is far better than TeamViewer's response to the same threat lately.
Related to password security: any of you guys using Chrome's ability to sync passwords to "Google cloud"?
I just started using it a few weeks ago. Supposedly it uses a password to encrypt the data, but I still don't feel too confident syncing them there. On the other hand.. damn it's so convenient between multiple devices.
I just started using it a few weeks ago. Supposedly it uses a password to encrypt the data, but I still don't feel too confident syncing them there. On the other hand.. damn it's so convenient between multiple devices.
There was recently a TeamViewer breach. Hackers somehow managed to access people's machines. Everything was denied and it wasn't investigated. Regardless, passwords were retrieved from Chrome. Some people lost a great deal of money.
Your browser is not a competent password manager and you should stop using it for that immediately.
Dashlane and LastPass make their money by keeping your passwords safe. This is far more preferable than a free browser feature. Both can sync across devices (if you pay). Sounds like you will like Dashlane for the same reasons that I do.
Your browser is not a competent password manager and you should stop using it for that immediately.
Dashlane and LastPass make their money by keeping your passwords safe. This is far more preferable than a free browser feature. Both can sync across devices (if you pay). Sounds like you will like Dashlane for the same reasons that I do.
How would LastPass protect you against another TeamViewer breach?
I assume it's the same with LastPass, but I use 1Password and that requires you to enter a master password to unlock the passwords, where as Chrome requires no extra authentication.
What do you mean? The whole thing can be encrypted with a master password, and LastPass offers an option to simply remember your master password with the browser extensions/desktop apps that I assume many people use.
> LastPass offers an option to simply remember your master password
It does, but it gives you a VERY strongly-worded warning when you enable that.
I like LastPass for a few reasons -
* It lets me share my personal account with my work account so I can keep them separate (so when I log in on my work PC, I still have my personal passwords, but I log in to my personal account on my devices so I don't have to worry about someone getting access to work passwords on there).
* 2FA
* If I try to set a master password that's the same as one of my passwords I'm storing in there, it warns me.
* Cross-platform
It does, but it gives you a VERY strongly-worded warning when you enable that.
I like LastPass for a few reasons -
* It lets me share my personal account with my work account so I can keep them separate (so when I log in on my work PC, I still have my personal passwords, but I log in to my personal account on my devices so I don't have to worry about someone getting access to work passwords on there).
* 2FA
* If I try to set a master password that's the same as one of my passwords I'm storing in there, it warns me.
* Cross-platform
1Password, at least, does not offer a 'remember master password' feature. I also configure it to auto-lock and auto-clear the clipboard on aggressive timeouts (I suspect other password managers allow for this too)
How would that help with the aforementioned TeamViewer breach? Unless your timeout is 1 min or less, the attacker can just watch and wait until you've logged in somewhere with LastPass and then quickly act.
The master password.
I use and love 1Password. Chrome is a terrible place to keep passwords due to what @zamalek said.
Passwords became hard to manage... now you have to choose >>different<< password for every site... Who can remember all those passwords? Only a password manager...
We need to ditch passwords, not continue to proliferate them with sandboxed databases.
Yeah? What kind of a secret can replace a password/passphrase? Not biometrics, those are username replacements, not password replacements.
Keys. That are approximately equivalent to long passwords, but have a standard length, and do not need sending through the network. They are also something you have, that can be protected by a password for 2FA.
But that just won't happen. So many sites can not even accept big passwords, they won't all migrating to any sane schema.
But that just won't happen. So many sites can not even accept big passwords, they won't all migrating to any sane schema.
They are password replacements in most contexts. The point of a password is usually just to verify your identity. Biometrics can do that just fine.
Biometrics can be fooled, and even if they couldn't they can only verify your identity. They can't verify your volition.
They can be fooled now, but that is an implementation flaw, not a problem with the concept. I wouldn't cite the weakness of unsalted MD5 hashes as a problem with the concept of passwords.
I agree with your assessment of what biometrics can and cannot do. That is why I specifically said that in most situations, passwords are only used to verify someone's identity, and thus can be replaced with biometrics.
I agree with your assessment of what biometrics can and cannot do. That is why I specifically said that in most situations, passwords are only used to verify someone's identity, and thus can be replaced with biometrics.
smartcards would be good for this.
Chip implants
How would that differ as a means of verification? It's not a known secret, just a different way of identification.
Not if the implant is writable. The xNT 13.56mhz NTAG216 RFID implant has 888 bytes of writable memory that could be used in this way.
It's really not hard. Generate passwords with 'pwgen -s 22' and store them in a gpg-encrypted file. emacs will prompt for your password when you open & when you save the file (there's probably vim code to do the same). Done.
It's not a completely ideal password manager, but it works.
If you can remember your password, then you shouldn't be typing it into a remote system, period.
It's not a completely ideal password manager, but it works.
If you can remember your password, then you shouldn't be typing it into a remote system, period.
That's really an awful solution compared to something like 1Password which has browser integration and synchronization between different devices. They even have a solution for groups.
Shameless plug time! Instead of remembering different passwords or using a password manager (and thus storing all your passwords somewhere) you can use https://salty.pw/
Problem with this is when you need a password with a capital letter, or with no symbols, or only 8 characters long.
Additionally, how do you determine the service name? e.g. I have a wordpress.com account; do I call that 'WordPress' or 'wordpress' or 'wordpress.com'? I guess using the domain name is fairly robust, but then you get stuff like Stack Exchange, or the service changes its domain name, or international variants - google.com vs. google.co.uk.
Additionally, how do you determine the service name? e.g. I have a wordpress.com account; do I call that 'WordPress' or 'wordpress' or 'wordpress.com'? I guess using the domain name is fairly robust, but then you get stuff like Stack Exchange, or the service changes its domain name, or international variants - google.com vs. google.co.uk.
Yup, arbitrary restrictions on passwords are a bane. I've thought about adding various modes but then you need to remember the mode you used. So far the most sensible option seems to be falling back to a password manager for those sites.
As for the service name I've had no issues with that in my use. Just come up with whatever rule is easy for you to remember. Worst case you'll have to make a few tries.
As for the service name I've had no issues with that in my use. Just come up with whatever rule is easy for you to remember. Worst case you'll have to make a few tries.
fantastic!
now a site has been breached and your username/password was leaked... yay, you'll have to either start using a traditional password manager for this special case or change every.single.password.you.have.
so useful ...not!
now a site has been breached and your username/password was leaked... yay, you'll have to either start using a traditional password manager for this special case or change every.single.password.you.have.
so useful ...not!
Or you could change the algorithm and make it unique to you. A bit more technical but the point isn't to be ultimately secure, just more secure than your 'neighbors'.
An interesting idea. Any thoughts on how to use this on websites that force a password change periodically? Using a versioned salt maybe, although that could get tricky after a few iterations.
Thats cool! Does it use simple concatenation or HMAC?
It's simple concatenation. The exact algorithm is described at the bottom of the page so that one could reproduce it (and their passwords) independently.
What about taking the 128 MSB vs 128 LSB, is there any research into how secure that is?
I vaguely remember giving it some consideration. But the bigger point is that my judgement on these things is not to be trusted since I'm just an application developer and not a crypto expert.
Yeah thats the thing, I'm not a crypto expert either but I'd love to use it. But if it gets popular, and there is an accidental mistake that actually makes it easy to guess passwords, I don't want to risk that happening.
Good news. Did a bit of investigation, it seems like this could be vulnerable to a length extension attack [1] (though the attack its still pretty useless in this particular case) but it appears that truncating is both safe and takes care of length extension attacks! [2]
[1]: https://en.wikipedia.org/wiki/Length_extension_attack
[2]: https://crypto.stackexchange.com/questions/18606/is-xoring-a...
[1]: https://en.wikipedia.org/wiki/Length_extension_attack
[2]: https://crypto.stackexchange.com/questions/18606/is-xoring-a...
Anecdote: I use an email account and a relatively simple password (3 relatively common words together) on LinkedIn. I don't use that email account much, but it was affected by the Linkedin hack. Today I get an email saying my Twitter account was accessed suspiciously (same credentials).
Power of the network effect that I won't leave Linkedin, and wouldn't think twice before spending money on the platform if I needed to recruit someone or do b2b sales. But screw Linkedin for not taking proper precautions.
Power of the network effect that I won't leave Linkedin, and wouldn't think twice before spending money on the platform if I needed to recruit someone or do b2b sales. But screw Linkedin for not taking proper precautions.
You're using a dictionary password and subsequently reusing that password on multiple sites.... and you're mad at LinkedIn for allowing your account to be compromised? Umm.
You are blaming the victim. Yes, they could have taken more steps to protect themselves, but those steps are inconvenient and cost everybody headspace and headaches. And if we're all being honest we don't use best practice every time we log into a website.
The real problem is the way that we do passwords. Passwords should either be managed by your browser or your operating system. When you log in to your computer, you log in one time with a public key. And then your OS/Browser automatically logs you into every website you visit by signing challenges instead of by giving your private key (that's essentially what a password boils down to) to everyone who wants to verify your identity.
The same is true for credit cards.
If we want a more secure web, we will replace the password system. It's difficult to use passwords correctly, even if you have the common sense (which a lot of people don't, because they just don't realize it's a bad idea).
It should be a higher priority. People are clearly losing money and losing quality of life over today's insecure password infrastructure.
The real problem is the way that we do passwords. Passwords should either be managed by your browser or your operating system. When you log in to your computer, you log in one time with a public key. And then your OS/Browser automatically logs you into every website you visit by signing challenges instead of by giving your private key (that's essentially what a password boils down to) to everyone who wants to verify your identity.
The same is true for credit cards.
If we want a more secure web, we will replace the password system. It's difficult to use passwords correctly, even if you have the common sense (which a lot of people don't, because they just don't realize it's a bad idea).
It should be a higher priority. People are clearly losing money and losing quality of life over today's insecure password infrastructure.
OP isn't blaming the victim. Op is playing with fire, KNOWS IT, and is surprised when they get burned.
Right now there are many solutions for password management. Free and open source, free and closed source, paid and closed source, enterprise. You name it! "Good password hygiene" is fairly ubiquitous amongst people on this site.
With that said, credential management[0] is coming. Google and Apple want to kill LastPass, 1password, and all these companies, and they definitely will AFAICT.
[0] https://www.w3.org/TR/credential-management-1/
Right now there are many solutions for password management. Free and open source, free and closed source, paid and closed source, enterprise. You name it! "Good password hygiene" is fairly ubiquitous amongst people on this site.
With that said, credential management[0] is coming. Google and Apple want to kill LastPass, 1password, and all these companies, and they definitely will AFAICT.
[0] https://www.w3.org/TR/credential-management-1/
I hope somebody kills off Lastpass. Worst customer support I have ever received. I've submitted 2 bug reports and 1 feature request since signing up for their paid plan all to have them thrown in their "won't fix" pile. I guess they're too busy making their interface bloated and hard to use to add functionality. /rant
There are many solutions for password management, but any solution that can work while travelling (in third-party computers), doesn't need a phone with a data connection, and actually works?
KeePass2? There's a portable version that you can drop on a USB stick, and it Works For Me™.
http://keepass.info
http://keepass.info
Not sure if I'm parsing your requirements correctly, but 1Password with Dropbox sync would work without a data connection as long as you sync the files beforehand. Works both for Android and iOS. Don't know if adding/modifying entries in the app while offline is possible; so far, I've only needed read access.
"You are blaming the victim"
Odd way of phrasing it. It's more accurate to say "you're pointing out that they have put themselves at risk through a number of insecure practises". It's not so much blaming a girl for getting raped; more "don't walk around an area that suffers from high crime, at night, using an expensive phone and getting a laptop and flashy camera and act surprised if you get robbed".
Odd way of phrasing it. It's more accurate to say "you're pointing out that they have put themselves at risk through a number of insecure practises". It's not so much blaming a girl for getting raped; more "don't walk around an area that suffers from high crime, at night, using an expensive phone and getting a laptop and flashy camera and act surprised if you get robbed".
I'm more annoyed about my email address being in the dump than my password (which is/was the shittest of my password set because I don't care about my LinkedIn account).
I, too, may even have used that pw on twitter (RIP both followers of my 4 tweet history). Again, because I don't really care.
I have essentially been re-using passwords for 15 years now (although my very first password on my AOL "gandalf" has long been retired), every now and again upgrading my "default strong" and using a the historical weaker ones on things I don't care about/don't trust.
Password Manager is definitely a smarter solution but I can't see myself setting it up.
I, too, may even have used that pw on twitter (RIP both followers of my 4 tweet history). Again, because I don't really care.
I have essentially been re-using passwords for 15 years now (although my very first password on my AOL "gandalf" has long been retired), every now and again upgrading my "default strong" and using a the historical weaker ones on things I don't care about/don't trust.
Password Manager is definitely a smarter solution but I can't see myself setting it up.
I would never have thought to set one up, but after taking the pain of getting all my passwords into it opportunistically (a few minutes per day for a few weeks) it saves me time and headache now. It can autochange passwords, keep notes for sites, and auto-login to websites. Very handy, plus I only have one password in my head now.
I'm in exactly the same situation. Strong passwords for what matters, the same weak password for sites I don't trust or care about.
I can walk around a bad part of town at 2am, but if I get shot, I'm still going to be mad at the shooter.
A mix of laziness, apathy and habit lead me to reuse that password on many sites. But I have 5+ email addresses, tons of shopping accounts, multiple banks, brokers, airlines, hotels, etc. I do use more secure passwords for other sites.
I really can't be bothered into using a password manager, so what's the alternative besides reusing passwords?
A mix of laziness, apathy and habit lead me to reuse that password on many sites. But I have 5+ email addresses, tons of shopping accounts, multiple banks, brokers, airlines, hotels, etc. I do use more secure passwords for other sites.
I really can't be bothered into using a password manager, so what's the alternative besides reusing passwords?
> I really can't be bothered into using a password manager, so what's the alternative besides reusing passwords?
The alternative is getting burned by password reuse repeatedly until you can be bothered, I would assume. Alternatively, you could cling to the hope that a more secure and more convenient authentication mechanism gets adopted somewhere in the next decade or two.
The alternative is getting burned by password reuse repeatedly until you can be bothered, I would assume. Alternatively, you could cling to the hope that a more secure and more convenient authentication mechanism gets adopted somewhere in the next decade or two.
> I can walk around a bad part of town at 2am, but if I get shot, I'm still going to be mad at the shooter.
I'm not sure calling LinkedIn the shooter in this analogy is completely fair; maybe more like the cop two streets over getting a donut.
I'm not sure calling LinkedIn the shooter in this analogy is completely fair; maybe more like the cop two streets over getting a donut.
LinkedIn released data that made the twitter breach possible. Your version is far too innocent. If we want to continue the badly-fitting analogy... how about LinkedIn is a guy dropping crates of bullets all over, in a world where stolen bullets have no non-crime uses.
just a random tidbit.. but the system currently allows you to set your password to what you previously had
I actually hope this is true as a consequence of them storing salted hashes for passwords. That is, Github should not ever see my password, only validate that I know what I entered previously.
It's pretty easy to keep a list of old salted hashes, and copmare the new password's salted hash against the previous ones. It doesn't require saving the old passwords.
If the salt changes, you'd need to compute the password using multiple salts, which might have crypto guarantee issues when sent to the server.
I don't follow what you're saying.
To compare your new password with your old password, you take the old salt, hash your new password together with it, and compare the result to the old hash. If they match, you're trying to reuse the same password. You do this on the server side, naturally.
To compare your new password with your old password, you take the old salt, hash your new password together with it, and compare the result to the old hash. If they match, you're trying to reuse the same password. You do this on the server side, naturally.
If everything is done server side, sure.
Why wouldn't it be?
If salted hashing were done on the client side, it means you're actually sending username + saltedhash, instead of username + password to the server to log in.
So an attacker could submit a precomputed or stolen salted hash to be compared against the stored one -- completely defeating the point of hashing passwords in the first place.
If salted hashing were done on the client side, it means you're actually sending username + saltedhash, instead of username + password to the server to log in.
So an attacker could submit a precomputed or stolen salted hash to be compared against the stored one -- completely defeating the point of hashing passwords in the first place.
>Why wouldn't it be?
So that the server never gets any plaintext.
>So an attacker could submit a precomputed or stolen salted hash to be compared against the stored one -- completely defeating the point of hashing passwords in the first place.
You could hash once on the client and once on the server to get the best (?) of both worlds. Really only the server one needs to be salted.
So that the server never gets any plaintext.
>So an attacker could submit a precomputed or stolen salted hash to be compared against the stored one -- completely defeating the point of hashing passwords in the first place.
You could hash once on the client and once on the server to get the best (?) of both worlds. Really only the server one needs to be salted.
I don't see what hashing on the client gets you.
>So that the server never gets any plaintext.
Mitigates attacks that exploit the server but not the served js.
See also https://security.stackexchange.com/questions/53594/why-is-cl... for some discussion: the first answer has the same thing I proposed, hashing on both the client and server.
I guess another benefit might be constant size passwords, which may mitigate side channels or sniffing.
How can it hurt? If there's no harm, but some upside, then why not?
Mitigates attacks that exploit the server but not the served js.
See also https://security.stackexchange.com/questions/53594/why-is-cl... for some discussion: the first answer has the same thing I proposed, hashing on both the client and server.
I guess another benefit might be constant size passwords, which may mitigate side channels or sniffing.
How can it hurt? If there's no harm, but some upside, then why not?
Since the resulting hash must be deterministic, you can't use a salt, and since you may login from crappy smartphones without JIT engines, you can't use many rounds. So the resulting hash will be trivially cracked using rainbow tables. The problem of variable-length passwords is better solved by only allowing the use of block ciphers in your TLS configuration, which you should probably do anyway.
As for the disadvantages, it makes logins take longer, forces the use of JavaScript, increases the complexity of code and increases the site size.
As for the disadvantages, it makes logins take longer, forces the use of JavaScript, increases the complexity of code and increases the site size.
>Since the resulting hash must be deterministic, you can't use a salt
You can as long as it stays the same over time. Either lookup salt by username (requires an extra call back and forth) or use a single salt for the whole site, or actually you could have the salt deterministically depend on the username. All of those defeat hash tables.
I agree that the password length problem is not a great benefit, but the benefit that the server never sees the plaintext is pretty good in my eyes.
Logins take longer: a single hash+salt won't make a big difference even on low end devices.
Javascript: fair point, although plenty of sites require it for signing in anyway. I suppose you could make it optional.
Complexity of code: if it's in a library and vetted this doesn't matter as much. Conceptually this is pretty simple, would probably be 3-5 lines of code (2 lines to hash, 2 lines to generate salt from username).
You can as long as it stays the same over time. Either lookup salt by username (requires an extra call back and forth) or use a single salt for the whole site, or actually you could have the salt deterministically depend on the username. All of those defeat hash tables.
I agree that the password length problem is not a great benefit, but the benefit that the server never sees the plaintext is pretty good in my eyes.
Logins take longer: a single hash+salt won't make a big difference even on low end devices.
Javascript: fair point, although plenty of sites require it for signing in anyway. I suppose you could make it optional.
Complexity of code: if it's in a library and vetted this doesn't matter as much. Conceptually this is pretty simple, would probably be 3-5 lines of code (2 lines to hash, 2 lines to generate salt from username).
You can store this hash on the server and use it as a password. If this hash gets stolen, the attacker will be able to log in on YOUR website, but not on other websites user may share passwords with.
After that you can ditch server-side hashing, and use authentication protocol like CRAM-MD5 (I don't remember what the modern alternatives are) to protect against network traffic interception. While still not technically storing your users' passwords in the database.
EDIT: Using asymmetric crypto with a private key derived from the password would probably be better. But still, client-side hashing DOES gain you something.
After that you can ditch server-side hashing, and use authentication protocol like CRAM-MD5 (I don't remember what the modern alternatives are) to protect against network traffic interception. While still not technically storing your users' passwords in the database.
EDIT: Using asymmetric crypto with a private key derived from the password would probably be better. But still, client-side hashing DOES gain you something.
I'm not following that logic. Using salted password hashing would not prevent them from checking your new password against the previous hash.
Why not do a site wide reset on every account?
It doesn't scale. I'd be fucking furious if services reset my password on every site because some other people reused passwords on one site that got hacked.
We'd all be dealing with password resets on a daily basis.
We'd all be dealing with password resets on a daily basis.
Probably because the only accounts that were compromised were those dumb enough to use the same password on multiple sites, and one of those sites to be compromised.
"We immediately began investigating, and found that the attacker had been able to log in to a number of GitHub accounts."
Did you even read what the OP asked?
As he said, those counts are obviously affected, but the article (and your quote) give no indication of if accounts in the other categories (attempted but failed, attempted but stopped by TFA) are also notified that attempts were made.
As he said, those counts are obviously affected, but the article (and your quote) give no indication of if accounts in the other categories (attempted but failed, attempted but stopped by TFA) are also notified that attempts were made.
The site guidelines (https://news.ycombinator.com/newsguidelines.html) ask you not to post did-you-even-read comments to HN:
Please don't insinuate that someone hasn't read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that."
In this case a comment rather than an article, but the rule still applies. Consider how much more polite your comment would be with just the second paragraph.
Please don't insinuate that someone hasn't read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that."
In this case a comment rather than an article, but the rule still applies. Consider how much more polite your comment would be with just the second paragraph.
We detached this subthread from https://news.ycombinator.com/item?id=11913690 and marked it off-topic.
I'm thinking that this is fallout from the LinkedIn breach, because this is the first high-profile breach which includes one of my e-mail addresses. (How do I know this? I'm using haveibeenpwned.com -- a free service that I highly suggest registering with.)