12 ms·
Hacker, Hack Thyself
- git_SHA 9y agoWould it be a bad security practice to keep a database of the SHA hashes of maybe the 10 000 most common passwords then alert users who try to use them? Obviously you would do the comparison before applying your actual bcrypt/PBKDF2 function with salt.
- OliverM 9y agoWouldn't it be easer to just test the submitted password against the 10,000 most common passwords directly, and refuse it then?
- proaralyst 9y agoWhich they already do; from the post: > Users cannot use any password matching a blacklist of the 10,000 most commonly used passwords.
- git_SHA 9y agoI read the post but somehow missed that. Sincere apologies.
- infogulch 9y agoMy question is, is 10k good enough? Wouldn't it be better to check against more? 50k?
- gwern 9y agoPresumably more is always better, but there's a very long tail of passwords so the hit rate will drop off a cliff, and now you're storing 5x as much data for increasingly questionable benefit.
- codinghorror 9y agothe problem is once you get to 10+ char passwords the common password list gets really tiny
- dukedougal 9y agoI built my latest application using Amazon Cognito for user management. My application and database don't ever know anything about the passwords. Amazon's problem.
- pibefision 9y agoConsidering OneLogin's current events I'm not sure if this approach is more secure or a good solution. (https://techcrunch.com/2017/06/01/onelogin-admits-recent-breach-is-pretty-dang-serious/ https://techcrunch.com/2017/06/01/onelogin-admits-recent-bre...)
- rekshaw 9y agoYou have two choices: try and do it on your own, or delegate to someone who you think can do it better. There are risks either way. Considering how much data Amazon has, they probably invest significantly more than you (or OneLogin) on security.
- sakawa 9y ago> Amazon's problem. Delegate to someone else™ isn't always the answer to your security problems. It only adds more complexity, no more or no less security.
- mod 9y agoIf my options were Amazon or roll my own, using Amazon would both 1) Decrease complexity, and 2) Add more security. This is supposing I am not a security expert and that Amazon has a good implementation. Of course, we all have libraries to use etc. It's still a pretty good option.
- CGamesPlay 9y agoWhile letting them handle the security options is probably going to result in a more secure system for you, it's certainly not "Amazon's Problem" when your database gets leaked and your user data gets out. For example, you're still going to have to explain to your users that you were compromised, and you're still going to show up in the haveibeenpwned list, not "An AWS Cognito Account".
- g_sch 9y agoI saw a very interesting talk last year from someone who, as part of a company's security team, had set up a system that continually attacked the hashes of every employee's Active Directory passwords. If one was cracked, the employee would receive an automated email with a note containing the last few characters of their password and a suggestion to change it. I recall they also spoke on some security aspects of the system's design, like how the cracked passwords never touched disk and had to be destroyed as soon as possible, etc. I wish I could find a recording or a writeup on this somewhere, as I thought it was a pretty cool (and effective) approach.
- mdpye 9y agoThe sysadmin in the CS computer labs at my uni (Leeds) was doing this in 2002. Changing cracked passwords was compulsory, you got an email that just said (paraphrasing) "Your password is crap" and then were forced to change it at next login. It was quite amusing, and instructive for the first year students. I seem to remember it happening to maybe 15 to 20% of people when I started, even though everyone was warned repeatedly. And this was with hardware and hashes from 15 years ago. Many (most?!) websites were still storing passwords in plain-text and didn't use TLS for log-in forms in those days!
- mike-cardwell 9y agoI used to work at a University in the UK. One of my responsibilities was the email system. We constantly suffered targeted phishing attacks where the sender pretended to be from the IT department and required the recipient to respond with their password, for various made up reasons. Our spam filters captured most of these on the way in, but some still got through. And people replied. People replied all the time. Students and staff. Even after being constantly informed about the problem and told to not reply to such emails. When they replied, the attacker would log in and start sending out spam. Anyway, the format of our passwords was quite strict. I don't remember the exact rules, but it required "special" characters and lower/upper case letters and numbers and a minimum length etc. So what I did was write a system to scan all outgoing email. It would search that email for all strings which matched our password pattern. It would then attempt to authenticate against the Active Directory with each of those strings. If any succeeded, it would block the email, and the person sending the email would get a response telling them to not send their password via email. I would also be Cc'd in, so I could keep an eye on it. This stopped several people a week from emailing out their login details to a phisher. I wrote about it here: https://www.grepular.com/Mitigating_Spear_Phishing https://www.grepular.com/Mitigating_Spear_Phishing - With links to the source code. I also later came up with a simpler solution and wrote about it here: https://www.grepular.com/Defending_Against_Spear_Phishing_with_Exim https://www.grepular.com/Defending_Against_Spear_Phishing_wi...
- mwcampbell 9y agoI wonder if Jeff and his team know about Dropbox's password strength estimator: https://github.com/dropbox/zxcvbn https://github.com/dropbox/zxcvbn
- nexxer 9y agoThey do, it's referenced at https://blog.codinghorror.com/your-password-is-too-damn-short/ https://blog.codinghorror.com/your-password-is-too-damn-shor... which linked in this post.
- peterwwillis 9y agoI'm comfortable using passwords <20 characters distributed among a range of sites because I have a realistic view: if one gets compromised, not every account does, and most accounts are not critical. Some are luggage keys, some are Medeco. But those are bad comparisons. A key and lock is an asynchronous single use authentication+authorization mechanism. Passwords are just the authentication part, so trying to replace these just requires we have a secure way to authenticate ourselves. We have the benefit that we are using digital systems, so our authentication can be digital, too. We can also rely on multiple factors to improve how authentic this process is. Biometrics, digital files, access to other accounts and networks, offline code generators, and personal information all provide lots of authentication data and multiply the effort needed to defeat the system. By combining all these factors, we can create a new digital key that is far more difficult to defeat than old methods by themselves, and ultimately is more flexible because it can be made up of any of these things. The problem mainly seems to be that we live in a world of different locks, and most locks don't accept this particular kind of digital key. We've hacked around this problem and made some attempts at more compatible solutions, but they really fall short of their true potential. In the future, you should simply be able to use any system and know that it will authenticate you in a way that can't be copied or cracked. Today that just isn't the case. So for now, maybe we should move the goal posts. We can keep making our keys more unwieldy, but we can also get more guard dogs. The guard dogs need to exist not only to protect the locks, but the keys, too. If you go to unlock a door, a thief can knock you out and steal your key. Each aspect of our digital access needs guard dogs. We can no longer accept insecure communication methods, nor insecure computing platforms, to exchange our authentication. I think the real challenge going forward is rethinking how we process data altogether.
- dublinben 9y agoIt's a lot easier than all of that. New two-factor authentication standards like U2F achieves most of that with just a simple, inexpensive hardware token.
- Bakary 9y agoU2F is cumbersome when you have to travel and change phone numbers frequently. In many cases there is no real way to have a line to one of your authentication methods, since you can never get the SMS confirmation.
- Qub3d 9y agoSuuuper nitpicky, but in the paragraph directly below Dark Helmet, Jeff calls his Graphics Card a 1080 GTX Ti. The GTX goes in front of 1080, since GTX is the general product line.
- neogodless 9y agoYou are correct. It is a mistake. It's also confusing naming, because not too long ago, nVidia named their cards with GT and GTX as a suffix, such as the GeForce 8800/9800 GT and GTX.
- wlesieutre 9y agoOnce they run out of numbers again maybe they'll turn it into an infix? Looking forward to the Nvidia 48GTX70!
- KeyboardFire 9y agopshh, that's nothing compared to the circumfixed Nvidia GT5790X
- codinghorror 9y agoall right, fixed, sorry about that
- dzdt 9y agoWhat this shows is that even with best practices passwords are a fairly weak security control. We need a standardised second factor id. The FCC or corresponding body elsewhere should mandate that phone networks and phones support a secure messenging protocol which could guarantee that a message could be sent to a phone number and only be received by that device. Password-only authentication is like locks on luggage, even with best practices.
- swsieber 9y agoWell, between Google authenticator (and apps like it) and keybase, it seems pretty much covered.
- criddell 9y agoSteve Gibson's SQRL project is pretty interesting. Right now I use TOTP whenever possible, but I think SQRL looks promising.
- Ajedi32 9y ago> We need a standardised second factor id We've already got TOTP (RFC6238) and U2F. At this point it's just a matter of adoption.
- raesene9 9y agoI'm not sure why you think this article shows that with best practice passwords, it's a relatively weak control? From the article a user choosing a random (i.e. not in wordlists) 8 character password with upper/lower/numeric characters could expect an attacker to take 3 years to crack the password (and that's attacking one hash!) Now to be clear, I totally think that passwords are a bad idea (mainly because humans aren't well equipped to choose and manage large numbers of random strings) but I don't really see why this article advances that concept?
- dzdt 9y agoQuoth the article: A very motivated attacker, or one with a sophisticated set of wordlists and masks, could eventually recover 39 × 16 = 624 passwords, or about five percent of the total users. That's reasonable, but higher than I would like.
- orng 9y agoIs my math failing me or wouldn't 8 digits result in 10^8 possibilities rather than 8^10?
- enzanki_ars 9y agoYou are correct. 8 digits = 10^8
- eriknstr 9y agoYou are correct that there are 10^8 possibilities for a string of 8 digits. 10 possibilities in position 1 10 possibilities in position 2 ... 10 possibilities in position 8 10 * 10 * 10 * 10 * 10 * 10 * 10 * 10 Alternatively one can even simply observe that 99999999 is the highest number possible and since 00000000 is possible also then we have 99999999 + 1 different possibilities = 100000000 = 10^8
- codinghorror 9y agomy bad, fixed
- peterclary 9y agoEncrypting the hashes in the database would make it safer. That way the password hashes can't be attacked in this way unless they can decrypt them first.
- a_imho 9y agoIs this method used/recommended? What could be the drawbacks?
- raesene9 9y agoEncrypting passwords wouldn't add a lot here unless you're using some mechanism to protect the encryption/decryption key (like using a Hardware Security Module), as an attacker who compromises the database is likely to compromise the key at the same time. If you do have a hardware security module, then why not just do away with hashing altogether, encrypt the passwords with AES-128 and you'll likely be fine (as long as the attacker can't extract the key from the HSM)
- bcoates 9y agoIt's slightly useful if you only give the key to your application servers, and not your database servers. Now you need an application server breach and not just read access to a database. It's not unheard of for something like a decommissioned database backup to wind up insecure and on the internet without being properly wiped, causing a whole-db leak without anyone actually breaking into a production system. Not sure it's worth the effort:reward though
- whoami_nr 9y agoI am not an expert on password hashing but I was wondering why can't the websites hash their passwords twice using two different hash algorithms. That way when the hashes are exposed, the attackers have to go through two algorithms. Is the time complexity increase only marginal that people don't do this ?
- raesene9 9y agoInstead of the added complexity of implementing multiple hash algorithms, if you're using something like bcrypt or PBKDF2 you can just increase the work-factor which makes the attacker (or indeed your application) do more work to calculate the hash. There's a risk, depending on your usecase and traffic levels that if you crank work factors too high, you can impact the users perception of your performance (e.g. a login operation might appear slow)
- whoami_nr 9y agoWhich is actually better in terms of time required to brute force(as in which takes longer) ? Two different fast algorithms with moderate work factors or one algorithm with a pretty high work factor ?
- raesene9 9y agowell AFAIK you can keep cranking the work factor as high as you like, so realistically one algorithm with a high work factor is likely to be better as it's a simpler thing to implement and has no drawbacks in terms of security.
- antisthenes 9y agoI think that's more security through obscurity rather than difficulty. Once the attacker figures out what the 2 hashing algorithms are, the scenario basically becomes the same as cracking hashes of 1 algorithm of increased difficulty (through number of passes) So, like the other answer implied, the increased complexity of maintaining 2 algorithms might not be worth the obscurity trade-off in the end. However, I am not a security professional either, so perhaps my opinion is not comprehensive enough.
- tarr11 9y agoHas anyone ever done an analysis of what impact these kinds of breaches (like OneLogin for example) have on either end users or the company? Ie, we often describe breaches as "really bad" but it would be good to quantify in terms of things like: - Revenue Lost (Company) - Reputation Lost (Company) - Time Lost (Company + User) - Increased Costs and Penalties (Company) - Assets lost (Company + User)
- eriknstr 9y agoOnce they have the hash type table in place they should switch to Argon2.
- novaleaf 9y agovery surprised nobody here or the author mentions Argon2, which is like scrypt except better, and is hardened against GPU attacks. https://en.wikipedia.org/wiki/Argon2 https://en.wikipedia.org/wiki/Argon2
- codinghorror 9y agois Argon2 ready for prime time and tested?
- novaleaf 9y agoyep, i use the npm package, it works great.
- tbabb 9y agoIANA security researcher, but isn't it a bad idea to publicly post a list of known-good passwords associated with accounts on your own site? I raised an eyebrow at the hash/salt table alone.
- bfstein 9y agoMy guess is they forced password resets on those users whose passwords were compromised.
- Sniffnoy 9y agoMost of those passwords that got cracked, my reaction is, OK, of course that's a weak password... but "1qaz2wsx3e" and "A3eilm2s2y"? Geez! How'd they get those?
- chime 9y ago> 1qaz2wsx3e That's just diagonals on the QWERTY keyboard. > A3eilm2s2y Apparently that's an in-game password for https://en.wikipedia.org/wiki/Parasite_Eve_II https://en.wikipedia.org/wiki/Parasite_Eve_II Commonly used passwords can be pre-hashed and easily cracked.
- Sniffnoy 9y agoInteresting, thanks!
- sriku 9y agoI don't trust myself enough to manage passwords properly for some small services I run 'cos I simply don't have the spare time to invest compared to investing in functionality. For that reason I've been trying out a password-less login for a while now (works via email) and so far non tech folks haven't complained too. It is pretty much as though you always used the "forgot password" mechanism to login. Wrote about it here - http://sriku.org/blog/2017/04/29/forget-password/ http://sriku.org/blog/2017/04/29/forget-password/
- psi-squared 9y agoThat's a really neat solution, and avoids the cognitive overhead of having to remember yet another password (or the security risk of re-using passwords). I particularly like the way you tie the log-in token to a particular browser session so that it can't be hijacked! Plus by merging all of the log-in paths (registration, 'forgot password', and normal login), you have one thing to design and secure rather than three. That seems like a huge advantage from a security perspective.
- kelsiq1 9y agoDo you need a pro for all your cyber and other related issues? You can contact one of the best in stealth software and equipment for spying and hacking and the anti. Do you need a change of identity? For more information on various solutions provided by the dark web contact- darkwebsolutions at hackemail dot com Text or call 16265153510 for more details