
Show HN: Evilpass – A slightly evil password strength checker - Sir_Cmpwn
https://github.com/SirCmpwn/evilpass?
======
jfroma
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.

DISCLAIMER: I work for Auth0.

1:
[http://www.dailymail.co.uk/sciencetech/article-3628950/Time-...](http://www.dailymail.co.uk/sciencetech/article-3628950/Time-
change-password-Facebook-Netflix-asking-users-tighten-account-security-
following-major-breaches.html)

2: [https://auth0.com/blog/announcing-password-breach-
detection/](https://auth0.com/blog/announcing-password-breach-detection/)

~~~
sametmax
Using a 3rd party to login is nice and all but:

\- 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.

~~~
jfroma
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.

------
dkokelley
I thought it was going to run the user through a wild goose chase of eccentric
and varying password requirements. This was better.

~~~
cmdrfred
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.

~~~
hyperpape
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".

~~~
randomguy42
Crap.

~~~
Achshar
Stop. The green color gives it away anyways.

------
socialentp
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.

~~~
anticafiamma
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.

------
agentgt
I'm starting to come of the opinion that systems should probably not let users
pick their passwords.

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.

~~~
dheera
Almost all of my passwords are:

    
    
        password = base64.b64encode(pbkdf2(master_password + '/' + domain, b'', 100000+n, keylen=16))[0:16].decode() + '$1Aa'
    

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.

~~~
nickysielicki
> 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.

~~~
keitmo
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.

~~~
pvdebbe
Paypal does it.

------
mikeash
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.

~~~
bayonetz
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.

~~~
finnh
That's not a sophisticated passsord scheme, then. Just complicated :)

------
bjt
An actually-useful alternative:
[https://github.com/dropbox/zxcvbn](https://github.com/dropbox/zxcvbn)

~~~
rohannair
The package size of that thing is ridiculous. Used it once in a React/Redux
app and it was about the same size as everything else combined.

Edit: 832kb apparently
[https://github.com/dropbox/zxcvbn/issues/169](https://github.com/dropbox/zxcvbn/issues/169)

~~~
smnscu
This is naturally due to having large-ish dictionaries embedded:
[https://github.com/dropbox/zxcvbn/tree/master/data](https://github.com/dropbox/zxcvbn/tree/master/data)

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.

------
TheBobinator
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.

~~~
bbcbasic
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.

Caveat Surfor

------
lvh
So, let's talk about password requirements.

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.

~~~
chadaustin
Those rules are encoded pretty well in this library:
[https://blogs.dropbox.com/tech/2012/04/zxcvbn-realistic-
pass...](https://blogs.dropbox.com/tech/2012/04/zxcvbn-realistic-password-
strength-estimation/)

Online demo at [https://www.bennish.net/password-strength-
checker/](https://www.bennish.net/password-strength-checker/)

~~~
ryan-c
A problem with zxcvbn fails badly at passphrase evaluation - for example it
will claim "all your base are belong to us" would take centuries to crack.

~~~
andybak
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.

~~~
ryan-c
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.

------
biot
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.

To be more specific:

    
    
      def _check_twitter(username, email, pw):
    

Yet it's called in check_pass as:

    
    
      if checks[check](email, username, pw):

------
ezekg
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.

------
jokoon
This is a genius idea.

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.

------
malikNF
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.

------
Schwolop
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.

------
atmosx
I understand the rationale. This would upgrade the level of a security of any
given website.

I wonder... Can a third party launch a script testing my passwords without
prior explicit authorisation? Could this trigger lawsuits/legal actions?

~~~
andreareina
Could be actionable in the USA under CFAA. Consult a lawyer.

Legality aside, actually using this is a bad idea all around.

~~~
WildUtah
Great. That covers the 0.01% of all crackers that live in the USA.

------
sova
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!

------
Spooky23
Just use diceware.

------
taf2
My favorite part of this is
[https://www.xkcd.com/792/](https://www.xkcd.com/792/)

~~~
weinzierl
Just out of curiosity: What happened in March 1997?

A list of Historical Events in March 1997[1] shows nothing relevant.

[1]
[http://www.onthisday.com/events/date/1997/march](http://www.onthisday.com/events/date/1997/march)

~~~
ekimekim
I always read that as
[http://tvtropes.org/pmwiki/pmwiki.php/Main/NoodleIncident](http://tvtropes.org/pmwiki/pmwiki.php/Main/NoodleIncident)
(a purposely dangling reference because the viewer's imagination is more
effective than anything you can say)

------
penglish1
Please change "password reuse is bad okay" to "password reuse is bad mmmmkay"

Thank you.

------
elastic_church
lol, this is hilarious

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

------
rootsudo
I like it. Evil enough.

I'll steal the idea.

