This server-side call to Twitter, Facebook etc is a bad idea. I understand you are trying to educate your users with a nice UX but let's say this software is running on USA but the user trying to sign up is based on France, the attempt of login can trigger anomaly detection algorithms (eg: impossible travel) and the user might receive an email from Twitter "someone has login across the pond with your password, if is not you please change immediately".
There are a lot of things that can be done though. Facebook and Netflix [1] for instance are crawling the web for leaks and pastes, once they find one of their user's password they will force the user to change their password. Auth0 is a authentication-as-a-service and we offer this as a feature [2].
I have worked on this feature and several related features, my advice is don't ask for a password in your public website. If you think is easy, you are wrong, it is a lot of work to code it correctly but it is also a lot of work maintaining the system. Brute force protection, anomaly detection, detecting when your user password has been leak by a third party, etc. It is simpler to authenticate by using a third party like google, you just have to be careful about implementing oauth flows correctly.
- if the party and you don't get along anymore, the accounts are dead. Some business are still counting the money lost from cloudflare deciding the underlying site is not respecting their conditions anymore. Same for Google translate. Auth is no different.
- if it has a technical failure, it's impossible to login. If you think it never happens, think again. We hear about a failure every year for some big companies. Because you don't have access to the code, you can't implement a quick fallback and must wait until they fix it.
- if their 3rd party account is compromised your site is as well. "Someone pirated my facebook" is something I heard to many time. It just meant that a close person from them maliciously used their account by accessing their computer when they were away, gaining access to everything.
- if their API changes, you need to change your code. Meaning you need to follow up on each providers. This can have a huge cost and the GAFAS really don't care and change their API at will.
- if the user closed their 3rd party account, they can't login anymore. This one is terrible : when I closed my gmail account, I became locked out of many services with not way of recovering them.
And then let's say you have one sass for auth (Oauth provider X), one for the db (firebase), one for map (gmap), one for static files (ES2), one for your messages (CloudAMQP) and so one.
Basically you own nothing in your infrastructure. You have no control on anything, you are dependent of a lot of things, and they all have you "clicked here to agree" on a lonnnng legal text that will update regularly and be affected by market and politics, across various countries.
All of those are very valid concerns and I agree with you what I tried to express is that some times developers underestimate what it means asking for a username and password in their websites.
For a proof of this, read haveibeenpwned.com. Troy blog is amazing.
If you are an startup, it might be better to invest your time in your idea and not poorly implementing authentication on your own. Yes, google might have issues but I am sure they have more engineers dedicated just to that thing, not only coding but also monitoring.
> let's say you have one sass for auth (Oauth provider X), one for the db (firebase), one for map (gmap), one for static files (ES2), one for your messages (CloudAMQP) and so one.
I hear you, I have been in both sides. When we started we used to use everything as a service because we didn't even understand how to manage some things like a database, as our OPs team grew we started to move things inside our infrastructure sometimes just to be able to restart them on failures. It is a trade-off and I guess it has a lot to do with the service you are hiring, SLAs, etc.
Which is useless if you don't have push notifications (ie are on iOS, where Google ended push support for Mail.app), because the attacker can just delete the email.
Whenever this happens to me (usually because I'm on a VPN), Google will block my email client from accessing my account until I log into their website and answer a security question. Before, I obviously can't delete the warning. Additionally, the email is also sent to my other address. It's not that easy for an attacker to log in without me noticing. The false positives are annoying, though.
This isn't intended for serious use, it's just intended to raise awareness about the dangers of password reuse. Also, Twitter sent me 2FA SMS messages during testing.
Great work and glad to hear it. Do you have any thoughts on a post-password internet? What are some cool not-password-login-schemes, if you've ever thought about it?
I'm not very good at thinking of technologies that work for non-technical users. Personally, I'm happy with password store + TOTP. Some interesting experiments I've seen include SSH and PGP-based challenges. I would like to see a browser-driven solution like better client-side certificates support, but none of these ideas work well for non-techies.
The vast majority of US government agencies use smartcard certs for authentication to web services, Google uses yubikey. Both are really solid solutions.
Okay, awesome. This makes me contemplate the following: physical identity links (such as yubikeys) are necessary in a real-world situation where credentials need to kept as securely. However, what about cases that
do not need such levels of security? It may make sense to have two groups: simple "identity assertion" & secure individual link. Do you feel me?
For many of my projects a compromised account would not be disastrous, or any more disastrous than a compromised HN account. It's simply a matter of ease-of-participation that one needs passwords in the first place for many of my applications.
everyone uses email for password resets anyway, and most people persist sessions. i always thought we should just email the user a link if their session has expired. there's no reason to have passwords.
this is the scheme sandstorm already uses.
maybe i find this less annoying since i have a dedicated terminal window for my email, and don't have to hunt around tabs for it? do people who use web-based email lose their email tabs?
>i always thought we should just email the user a link if their session has expired. there's no reason to have passwords.
Yes! You are so right. What have I been thinking. This is an excellent and care-free way to do it. I didn't even consider persisting e-mail tokens, but that makes so much sense! Thanks!
An alternative to passwords would be great but giving all my data to google, or to any other 3rd party, is a no go in term of privacy.
What I wish for is an authentication protocol that doesn't rely on a third party. I really like the idea behind SQRL, but it's unlikely to take off. Storing a private key on a reasonably secure platform like an iphone, and that key is used to derive unique keys for each website.
That is part of what U2F is trying to do. The specification is little too complex, but deriving all the site-specific keys from one master secret without any additional token-side storage is one of possible implementations.
But does U2F require a USB device? Where Gibson's SQRL I think is smart is that since it uses a QR code to do the challenge response, it is compatible with every platform, including those that do not have a USB port (think of a corporate workstation where you are not allowed to plug a key, or a MacBook Pro when you don't have the right dongle, or a tablet).
In term of user experience, the website shows a QR code, all you have to do is to show the challenge QR code to the phone, the phone connects to the server directly with the response, and you didn't need to even type a login or password. The security is basically handled by your phone, which if it is an iphone has a fingerprint reader, secure enclave, encrypted disk and wipes out the data when brute forced. Not 100% secure (nothing is) but better than 99.9% of alternatives solutions, including password managers living in Windows, an open environment full of potential malware.
I just wish it had a more consensual / well known sponsor. I think the idea could really work.
I hate it when a service doesn't have a way to use a password but instead forces me to use a 3rd party. Using a 3rd party like google for the password is a breach of my privacy. I do not want to give too much data to facebook or google.
It is a very valid point and I agree with you. This is a known fact; if you sign up with a social account you give up on privacy.
When you sign up in a service with a username and password there are a lot of unknowns. Do you know if their understand security at all, if your password is properly stored, if they protect your data from brute force attacks, timing attacks, etc.
True but if I signup with a username and a password, I use a random password, the email I use is specific to that service and I only answer 'security' questions with random data that is then stored in a local password manager.
Now I'll admit this is not the behavior of typical users but I like having that possibility.
Same here. From the source it checks Twitter, Github, Facebook, Reddit and Hacker News. This also might prove that email addresses as usernames is a bad idea.
People generally tend to try and get same username on most websites they visit. Especially the ones using same pw everywhere. So in that sense email as UID ain't that bad.
Probably, but the alternative isn't much better. Many people I know are "randomguy42" on dozens of different services, except for a few shady ones where they're "definitelynotrandomguy42".
This is compared to the very evil password strength checker, which gives an ambiguous "password not strong enough" error until it finds a match with another service.
Have any bad actors even been implicated in this kind of abuse??
It'd be interesting to try to automate honeypots to screen for this -- for each suspect site, unique credentials which are also reused on honeypot accounts on other major common target sites.
where master_password is not written or stored anywhere, domain is the domain name of the service in question, and n is the nth password generated for the service in question (since some services force you to change passwords every N months).
'$1Aa' is to appease stupid websites that require a symbol, number, uppercase, and lowercase letter.
Truncation to 16 characters is to appease stupid websites that limit passwords to 20 characters.
I also use the same thing for the answers to all "security" questions online, where I just plug in the security question as domain. (They're basically de-security questions, since, you know, a lot of people in this world know what my favorite color is and what streets I used to live on).
I should probably use HMAC but whatever.
The only passwords I have that are not part of this system are my computer's root password, e-mail password, and bank account passwords; for those I just memorized random strings).
This system gives me the following advantages:
* Peace of mind that I don't have to trust a 3rd party, closed-source password manager
* No need to cloud-sync anything across machines. No need to access the internet.
* I can calculate my passwords without a database, so if I have to randomly reformat my machine while travelling I can still compute my passwords and login to everything I need to.
> Truncation to 16 characters is to appease stupid websites that limit passwords to 20 characters.
This is something that drives me up the wall. I understand that you have to impose some kind of limit on password length to avoid abuse, but there's virtually no reason to cap it at anything less than 32 characters. I think a cap of 128 characters is completely reasonable and likely to appease even the most paranoid of users-- it all hashes to the same size anyway.
Another thing that irritates me is when registration forms enforce max password length via javascript or maxLength, without describing the max length in writing somewhere on the page. If I generate a password and I paste it into that field, I have no way of knowing if it has been truncated or not. I can't count how many times I've registered for a website and then had to immediately recover the password because of this. The time that stands out most to me is when this happened with my bank! Come on!
Pro-tip to any web developers out there: providing some kind of visual cue that the password I've entered is at the maximum length of the field (and that it was possibly truncated) is a good solution to an edge case that I feel is rarely considered.
I had something similar happen on a financial site years ago. The logon page silently truncated passwords to N characters, while the password reset page silently truncated to N+1 characters. My default randomly generated password length was, of course greater than N+1.
That type of truncation virtually always happens in JavaScript in my experience, leading to my favorite greasemonkey script; showing what happened to the text in a masked edit field in a pop-up window on form action.
I tried to do something like this but ran into two problems:
1. it's not always clear what the domain is. Sometimes a company has more than one portal to enter a login. Now I have to remember which one I was using when I created the account. I can try to use the company name but that's ambiguous as well because sometimes the portal's or product's name is different from the company's name and now I have to remember what the "domain" is.
2. Different services have mutually contradictory requirements for passwords. You mentioned you add '$1Aa' to appease some websites, but I have encountered ones that have a no symbols rule, or some that have minimum length 12 while others that have maximum length 10.
I believe the most reasonable solution is to use a password manager.
One option would be to host a public text file (on Github, even) that describes various services, their password requirements, domain aliases, and have the script tack on the approriate strings based on the public text file. Others could even use the same script and submit pull requests describing new services they encounter.
My main objective is to eliminate personal databases.
Okay, so say I submit a pull request for a phishing domain pretending to be an alias of something, and months/years later trick you into visiting it. Seems risky to me.
This would only be risky if I got phished into visiting your phishy domain AND was stupid enough to consciously want to enter a password into it, in which case the risks are the same as if I used a human-memorized password.
My password "manager" doesn't automatically fill in passwords until I consciously ask it to.
But some amount of human oversight over those pull requests would be in order.
I wanted to do something similar with a slightly different formula but got into major issues. I couldn't log in from any other computer without opening a terminal and typing code for two minutes. I couldn't use it from a mobile on the go. key logger was even more dangerous since now the attacker could learn all my passwords instead instead of just one.
I don't run the computation on devices I don't own, in case my master password gets leaked by a keylogger. If I have to login to a non-sensitive site on someone else's machine, I compute the password on my phone and the type it in manually.
The clipboard is indeed unsafe. I don't use the clipboard. On my Linux machines I use xte (apt-get install xautomation) to have my script enter the password after a delay of 3 seconds which is enough for me to switch windows and click on the password field where it needs to be entered.
On phones I just type it in after looking at it, or compute on my computer and punch into my phone. I can memorize a 20-character string for a short time. In the future I might make a device to plug in via OTG cable, emulating a USB keyboard, to enter the password into phone apps. Another option for phones is key injection using /dev/uinput which is accessible if you run Cyanogenmod.
I did something similar to this for a long time, but had constant headaches because URLs and domain names often change for services as companies consolidate, etc. Drove me nuts, I had to remember the old domain name. Now I just use 1Password (which may or may not be the best choice in password managers).
There are apps that do this, the magical password generator that doesn't need to sync anything.
However, this well known method has many flaws:
* very hard to satisfy all site-specific password requirements (need symbols, no symbols, at least 8 characters, at most 8 characters, etc. etc.)
You can work around this by storing site-specific requirements, but then you need to sync again, basically.
* very hard to version: if LinkedIn screws up again and you need to reset your LinkedIn password, but don't want to replace all your other passwords by changing the master password, what do you do? You can version by including a version number or so pre-hash, or increase the number of rounds (as the GP suggests) but then you need to sync the version number (or remember it or try), so you're back to square 1.
* Also, might want to use Scrypt or Argon2 or so instead.
There are other problems. See related HN discussions for these frequently suggested storage-less "password managers":
A Python script on my Android phone computes the above. I might write a native app later. I'm also thinking of making something at my desk that emulates a USB keyboard that I plug into my phone with an OTG cable to enter the computed password automatically.
For less-sensitive sites (i.e. things that aren't going to screw me over if my account is hacked), I just save the computed password into the Chrome password manager. The computed password can't be feasibly used to get my master password anyway.
For many sites it's possible to stay logged in with a session cookie without saving the password.
Sounds like you actually want client certificates.
If only our ancestors didn't so royally screw that up.. they took the brilliant public-key crypto and even just through the bazillion different encoding schemes and various "cert store" madness have made its use entirely untenable. The whole "the service can't know the password" problem was entirely solved and look where we stand today.
The foundation is solid. The UI is terrible and browser vendors don't do anything about it (sort of catch-22 here)
A sane certificate management UI (not hidden beneath 5+ clicks, and not full of useless distractions like "software security token" that scare users away), key escrow protocol (opt-in), transparent certificate sync (yes, has downsides, but no worse than password sync), and some JS APIs to manage certs - that can do miracles. But that won't happen.
Sorry, this doesn't look attractive to me. Among the downsides I see, the important one is that it requires a whole new software stack. That had been tried many times - I'm afraid, unless you have some really huge corporation backing the project (one that can really push it), it just won't fly.
What's good about TLS is that it's ubiquitous and you don't need anything special to deploy it. Got nginx, Apache or Caddy? Add a single directive (e.g. ssl_verify_client for nginx) and you're almost there, all the validation is already implemented, just tie the keys to your accounts system.
It was used on startssl.com, at least before they got in cahoots with wosign and subsequently got de-listed as a CA for various shady practices. I haven't checked since.
Also, I think Chrome is in the process of removing support for <keygen> (and client side certificates in general?), so whatever opportunity existed for making this common has now passed.
I remember this on startssl.com, and experience (or at least Firefox's implementation) was horrible.
-I had to refresh certificate once per year, which is very inconvenient, as I would go to startssl.com once per year total
- Half of the time something would go wrong with keygen in firefox and it would not remember my certificate at all. This is when you discover that all the security is simply bypassed when you send email to support.
- And worst of all, it was not very secure at all -- a malware on my computer would totally steal a certificate and keysniff the password for it. Compare with Google Authenticator or SMS auth, where I would be safe as long as my cell phone is not compromized at the same time.
True, the implementations were lacking some finesse. But a proper keychain type cert store handled by the operating system should in theory be able to protect the certificate against usermode malware (perhaps by only coughing up the certificate to an application signed with the same code signing ID as the application that inserted the certificate, and/or after an elevated password prompt)
It was used on an IE-only project I worked on many years ago. It was very difficult for users to manage and was used in addition to individual credentialing with a username/password. The certificate would identify the physical location, so there'd be one per client installed onto all the machines from which the site could be used.
Chrome blocked client certificate generation by default from version 49, I think you have to enable it specifically now and in general the process is messy (difficult to tell if your private key info is lost or where it ended up).
Firefox still works. No idea if people use it for auth, but it is popular when requesting a certificate.
the rng in js is not good enough for crypto. but if you send the cert including key to the browser most browsers know what to do and will auto use it. there are different formats for different browsers though. and the server also needs to have a cert
Emojis in passwords would both make passwords more secure and easier to remember for some people. The drawback is that they're very hard to enter in normal, physical keyboards.
Another problem that's easy to overlook until it isn't is entering your password in front of people - if you're selecting stuff on screen then that's a lot more likely to be seen than typing on the keyboard.
> If password is short, it's still gonna be quick to crack
Only if the cracker is brute-forcing instead of using common passwords mixed with dictionary words, and if the brute-forcer thought to implement emojis. Given how many emojis there are, it would by psychotic to include them in a brute-force attack unless you already know the person used emojis.
There are ~1800 widely supported emojis. That blows out the search space. There are 10^19 possible passwords for a 6 character alphanum+emoji, the same as a 10 character password using just alphanum + simple keyboard symbols.
But what's the actual distribution of usage of emoji? I'm guessing there is a small-ish set that people actually use, just like there is a small-ish set of words that people will pick from if you ask them to pick a passphrase containing "random" words.
Unless you pick the passphrase for them, you're not really gaining the advantage of the search space size.
Except people will probably stick to a few common ones and do a pattern. Love eyes x2 heart heart, thumbs up -- just like people don't pick words uniformly.
If they're randomly generated, are they still going to be easy to remember? User-chosen emoji passwords would probably be even weaker than user-chosen passphrases.
This requires that everyone uses password managers that either work across all their platforms or that they know how to access and look up passwords for. I don't think the general user is ready for that.
I had proposed a similar idea at my last place of employment at a smaller University when I was spearheading an initiative to revamp our identity management system. The system itself needed to be rebuilt at it was hacked together by our former Systems Lead to replace an ancient server that handled everything, and while it worked, it was far from ideal.
Initially we just wanted to implement zxcvbn and be done with it, but due to some in office politics, we had to take it a step further and do a password policy review; our federated login across so many systems resulted in some really bizarre password requirements, so we wanted to simplify it and push users towards passphrases for more secure passwords.
The idea I was pushing was that we'd basically just spend an afternoon coming up with as many benign questions as we could to get a list of about 400-500 some questions, on account creation, the user would be queried for 3-4 of the questions randomly, and a system would generate a passphrase based on the answers provided with a bit of security fuzziness (maybe a substitution or two, random order, underscores or spaces, etc) to the passphrase to ensure it met what zccvbn considered secure.
I'm not a security guy as much as I'd like to be, so I don't quite know what harm there is in such a system, but it seemed like a good idea at the time. The biggest problem as we could tell it would be the user would forget the password or be annoyed by long passwords, and even if you knew the entire list, it seemed unlikely you could figure out which questions they got and in what order, and the number of questions seemed to prevent even educated guesses by spouses/stalkers.
It was ultimately shot down by politics because the President of the University couldn't come up with a valid password using this system. (he insisted he must be able to use his password scheme, which it turns out always included the university mascot name, which was part of the forbidden list) Currently I think it just runs with the simplified rules requiring at least 8 characters and meeting a security rating of at least 4 per zxcvbn.
Keep in mind that, a lot of really poorly designed system are not sanitizing properly user input. I am prepared to bet a lot on the simple idea that an UTF-8 password might break so much of them...
> That is they get to pick a generated password (by the system) that is easy to remember. Maybe from 10 or so.
I think we need to get away from the idea that people should memorize passwords at all. The default should be "generate long password (or encryption key for sites that support it) and put it in your browser's password manager". You only need to memorize the main passphrase for your system-level encryption.
If maybe 5% of the accesses the site requires authentication (the other 95% passthru cause you have the cookie) - make that 5% use a text code to your phone.
EDIT: App on yr phone, not an SMS
Yet another reason to use SMS encryption (which seems oddly rare) like SilenceIM (formerly SMSSecure, formerly the dropped SMS code in TextSecure [now Signal]).
Not losing control of your phone. Losing control of your phone _number_.
There's plenty of stories around of spear phishing attacks involving attackers taking over the victim's phone number. Mobile operators are notoriously vulnerable to that sort of shenanigans.
systems should probably not let users pick their passwords.
That is they get to pick a generated password (by the system)
It implies that the system knows plaintext password. Even if the system deletes the password and keeps a hash, it remains the problem of distributing that password to the client in a secure way.
Depends on the system. If it's a website of some description you could always generate the password in the clients browser. Obviously you'd then need to be pretty careful to generate your suggested passwords in a secure way, because any attacker would have visibility of your password generating system.
>It implies that the system knows plaintext password
No it doesn't, the password can be generated client side. I know that client side code is not safe, but the purpose here is to protect people who are not tech savvy enough to figure that out.
With the difference that when user types the password it is not displayed on the screen. Server-side generated password must be somehow presented to the user.
This is an interesting concept. It gets me thinking: what exactly makes this "slightly evil"?
It's not actually doing anything nefarious. It checks to see if it can use your credentials to access certain sites, but it doesn't actually do anything with them besides tell you that it worked.
There is of course the potential for doing nefarious things using your credentials on other sites. But... all software which receives a username and password has that potential.
I can only conclude that it's "slightly evil" to point out the possibility.
This reminds me of something I've worried about from time to time. I have a fairly sophisticated password scheme from before there were good password managers. I don't have unique pass per site but close to it. I still forget sometimes which goes where and end up entering in real passwords just that are for other sites. There are probably a few sites at this point that have seen me enter in all my real (but wrong for that site) passwords. All some evil actor would have to do is keep a log of my attempts at one site and they could get pretty far with getting all my passwords. It's pretty scary.
If you think long and carefully enough, you'll find out "evil" is just something that would offend or harm other people.
Showing that you can log into someone else's account with info they provided you is like saying "dude, you stupid".
And even though your intention is for them to take care of themselves, they will, instinctively take that as an aggression.
Sure it's not as bad when it comes from a website, but I bet you know how people react when you try to teach them something they don't wanna learn.
Attempting to login to someone else's account without permission is clearly unauthorized use of a computer system. People have gone to jail for much less.
It's hitting a load of third party services - for its own benefit - that were never intended for that purpose.
I would hate to run a service and find some freely available script was letting anyone use it in an automated fashion. It's like what happened with the whois system and the catchas that providers had to add to prevent abuse from scripts.
Some people in the thread you linked to recommend lazy loading, another idea would be to use a bloom filter – I used this in a project to check server-side for hashes of (MMs of) common passwords.
Excuse me, it's less than one MB for actually useful (and rarely used) functionality, in a time when many websites routinely weigh in at several MegaBytes for tracking, advertisements, silly pictures and other cruft.
It is very noble that you are concerned about page size (seriously, I frequently travel and am on awfully slow WiFi or mobile networks (remember GPRS and Edge?) and hate wasteful websites with a passion) - but I'd much rather you remove all the other cruft (seriously, how much can two fields for "Enter username and password" take?) and include the most excellent zxcvbn.
One of the fundamental problems is most developers dehumanize people by referring to them as users, which that term might as well be synonymous with robots given how developers think about them. This "slightly evil" approach is humorous, but in all candor, silicon valley has a serious disease of treating people like cattle and that's the kind of attitude that generates this kind of project. Of course, without respect for your customer base, you really can't have integrity or respect for yourself, which is why many of the jobs out there are so brutal. If the company doesn't respect it's customers, it doesn't respect itself, and it sure as heck isn't going to respect it's employee's. The biggest and most profitable technology companies in the US are not trustworthy due to this. At this point it's habitation and embedded so deeply into the thinking I'm not sure it'll ever change.
There's a fundamental lack of respect for simplifying the whole ordeal of authenticating; do it in such a way someone would need to know exactly how the authentication works and what the risks are if they were scammed.
E.G. First page listing what someone could do to you if they got your password so they can assess the risk. Second page indicates the requirements and gives some examples. Third page asks them how they want to manage recovery should they forget their password, and whether they want to be notified. Change the business risk or the password requirements? Update and put all the users through the whole process again.
I think this repo exists for ironic purposes. It does recommend not to use such a system to check passwords.
I think it serves as a warning that any site could do this, so be careful. Furthermore (and more evil) is to record all user input into forms using Javascript so if you mistakenly enter another site's password and then realize your error - they have it anyway.
The README suggests that instead of this, you should check entropy. That's a little tricky! Entropy in the traditional information-theoretic sense is a property of a random variable. You need to know what distribution a user drew it from. You can make educated guesses (e.g. if long, probably using password manager, if using password manager, probably fixed length) but that usually only tells you something useful about the _good_ passwords, and not the bad. You don't care about the good passwords. If the user entered "correct horse battery staple" but the user _always_ uses that password, a sufficiently informed attacker experiences 0 bits of entropy.
So, entropy estimation is pretty bad, and we end up with imperfect password rules. Here are some ideas:
1. Make an educated guess about the distribution. Is it "correct horse battery staple"-like? Because then maybe don't tell people to add special characters if it's long enough. Relaxing requirements when people add numbers is tricky; turns out people are really likely to add those numbers at the end, and then it's probably a bad reused password like sparky1 or whatever.
2. Filter extremely common passwords, and things directly linked to usernames.
3. 8 <= len <= 70 or so (otherwise you'll get probably-bogus Hackeroni submissions about DoS).
4. No scheme will save your user from shitty passwords. bcrypt, scrypt, argon2, whatever -- not an excuse for not protecting your password database.
5. If you wanna be really fancy, use your guesstimate about the source distribution to produce an entropy estimation. Entropy is the nerd-proof answer, but most consumers don't know what it is. Whether or not telling users something like "try making your password longer" or adding a new class of special characters is friendly UX and whether that actually makes them use significantly better passwords versus the moral equivalent of sparky1 is an open question; I don't think it's an unreasonable assumption that both work out worse than you might hope.
It's important to note that this doesn't need to be perfect (and strictly speaking, it can't be). You just need to stop non-advanced users from shooting themselves in the foot, and ideally prevent power users from being annoyed at your service.
I should really turn this into a library :-) But before you do any of this fancy stuff? Implement 2FA, ideally U2F. No work you do on password rules is going to compare to what you get if you allow shitty passwords, but most of your users use U2F. Just get started now. I know U2F has limited distribution right now. That's a chicken or the egg problem. You can do TOTP too, but trust me, U2F is way, way better.
If you haven't seen it before, zxcvbn [1] seems like a good attempt at automating these things, and there are ports of it in many popular languages. It's been in use in production at Dropbox for several years, now, so I'm hoping the ideas and implementation have been vetted pretty well.
(I have no Dropbox affiliation, I just found the library a while back and thought it was a great way to keep passwords secure while getting rid of arbitrary requirements focused more on SQL injection than password safety.)
I assume you mean "it's long but a commonly chosen long password"
Do you have evidence that is a commonly used password? I'm genuinely curious. The people geeky enough to know that meme might be slightly more likely to understand why it's a poor choice of password.
It was just a random example, but a couple years ago I found 250 BTC with a private key of sha256("how much wood could a woodchuck chuck if a woodchuck could chuck wood"). People use quotes from movies/tv/books/etc for stuff that matters.
Still better than most other password quality checkers.
In a sense, they can all only tell you that something is certainly a bad password, or maybe a good one. It's a very hard problem, and zxcvbn does a much better job than most (more naive) tools.
It estimates 79.6 bits of entropy. It's basing the estimate on just the words, not on the popularity of the phrase as a whole.
Let's compare that to https://www.grc.com/haystack.htm which many people promote as a good password checker, but is actually terrible. It claims 177 bits of entropy. This is basing the estimate on just the individual characters.
Email and username are transposed compared to the site check function signatures. I'm sure someone will send a pull request to fix that and make it slightly less un-evil.
Maybe I'm just grumpy, but I'm sick and tired of seeing 'joke' libraries like this. Not the kind of stuff I look for on HN and it's becoming more common.
In my opinion, facebook, twitter, google and others should work together to prevent their users to share a same password in their platform. It would be a win win.
Of course I have really no idea how to implement such a thing securely, since government platforms would obviously try to peek at how it would be done.
Wouldn't doing something like this on a live site constitute as a social engineering hack? Hope the author of the projects leaves a very visible warning to anyone who might actually consider including something like this on their applications.
Here's a thought web devs. You know how your website has a 'reset my password' flow? How about you just use that on its own, and not have passwords at all?
I recall one website I visit does this, but I can't remember which one.
By mere virtue of showcasing the irony in providing passwords and their re-use I must tip my hat to you. You have done more as a security activist with a simple project than most people do with 100 blog posts!
"This could possibly refer to the March 26, 1997 incident in San Diego, California, where 39 Heaven's Gate cultists committed mass suicide at their compound. It is a plausible explanation, since one of them was the brother of Nichelle Nichols (a Star Trek actress), so the event got a big resonance in nerd circles (and Randall often refers to Star Trek in xkcd). However, given Black Hat's strange behavior, it could be anything, even Bill Clinton banning federal funding for human cloning research."
There are a lot of things that can be done though. Facebook and Netflix [1] for instance are crawling the web for leaks and pastes, once they find one of their user's password they will force the user to change their password. Auth0 is a authentication-as-a-service and we offer this as a feature [2].
I have worked on this feature and several related features, my advice is don't ask for a password in your public website. If you think is easy, you are wrong, it is a lot of work to code it correctly but it is also a lot of work maintaining the system. Brute force protection, anomaly detection, detecting when your user password has been leak by a third party, etc. It is simpler to authenticate by using a third party like google, you just have to be careful about implementing oauth flows correctly.
DISCLAIMER: I work for Auth0.
1: http://www.dailymail.co.uk/sciencetech/article-3628950/Time-...
2: https://auth0.com/blog/announcing-password-breach-detection/