Show HN: Evilpass – A slightly evil password strength checker
github.com
github.com
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/
Isn't that exactly what they should do though? They just Spicered their Twitter password...
Google is sending an email every time you login in a different OS or browser even if you are on the same city.
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.
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.
Do you think a "drawable" password would be cool?
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?
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!
- 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.
Your entire business is at the mercy of others.
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.
Now I'll admit this is not the behavior of typical users but I like having that possibility.
And the perfect reaction: "Ohhh, OK. Wait, what?"
That is they get to pick a generated password (by the system) that is easy to remember. Maybe from 10 or so.
There are password generators that use multiple words but are really long (eg you have probably seen the new router passwords that are like this).
I have even thought maybe emojis might make for better passwords for some users.
But does it really improve security that much? If password is short, it's still gonna be quick to crack.
Unless you pick the passphrase for them, you're not really gaining the advantage of the search space size.
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.
PS. No I don't use it anymore. And yes xkcd 936 was my inspiration.
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.
Firefox still works. No idea if people use it for auth, but it is popular when requesting a certificate.
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.
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 is new (tiny and well thought through) API but nobody used client certs anyway, as we found out in this very thread.
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 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.
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
No more passwords.
1. every site to obtain some automatable way to send text messages, which can get mildly expensive,
2. people to acquire at least one burner phone for authentication because they don't want $randomwebsite to have their real phone number, and
3. users to give up some degree of anonymity because the country of origin can't be hidden behind a proxy, as the phone number gives it away.
This sounds like an overall loss for everybody to me.
https://www.wired.com/2016/06/hey-stop-using-texts-two-facto...
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.
I'm not sure about Microsoft, but Google supports several other 2FA mechanisms in addition to SMS.
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.
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.
That's no different. It uses the same channel the user would send the password to it.
password = base64.b64encode(pbkdf2(master_password + '/' + domain, b'', 100000+n, keylen=16))[0:16].decode() + '$1Aa'
'$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.
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.
What does this give you that, say, KeePass doesn't?
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":
4. You will need a clipboard everytime to copy paste which is not very safe
Suggestion: Add a salt parameter to make it less deterministic, keep these salt in a personal database
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.
Now I see why such a system works for you. Very few people can do that in case you didn't know.
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.
By the way what do you do when you have more than one account or when the website wants you to reset your password (because they leaked it again...)?
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.
My main objective is to eliminate personal databases.
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 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.
hunter2-esque "how do you know my password?!" would be rife!
If I want to log in, an e-mail is sent to my mail, and an optional 2FA on my mobile.
If my mail is compromised, all the other passwords can be reset anyway.
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.
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.
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.
Edit: 832kb apparently https://github.com/dropbox/zxcvbn/issues/169
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.
If you're using React/Redux, you probably have a build tool like Webpack setup, which makes loading async dependencies pretty painless.
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.
At least on the server side, size doesn't matter quite as much.
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 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.
Caveat Surfor
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.
Online demo at https://www.bennish.net/password-strength-checker/
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.
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.
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.
(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.)
Sorry for the stupid question.
To be more specific:
def _check_twitter(username, email, pw):
if checks[check](email, username, pw):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.
I recall one website I visit does this, but I can't remember which one.
I wonder... Can a third party launch a script testing my passwords without prior explicit authorisation? Could this trigger lawsuits/legal actions?
Legality aside, actually using this is a bad idea all around.
A list of Historical Events in March 1997[1] shows nothing relevant.
"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."
Thank you.
I use so many different email address and usernames - along with a password manager - that I would undermine the usefulness of this project
many times I also use a password manager for the username itself, completely random
I'll steal the idea.