Re XKCD 936: test the safety of your passphrase entirely in your browser | Hacker News Reader

Re XKCD 936: test the safety of your passphrase entirely in your browser

leebutterman.com

29 pointslsb48 comments

Two problems with this page:

1. I entered "test for bob" as a test passphrase and it told me that "The word <bob> is an uncommon word." Might need a better word list.

2. More seriously, it should simply mark every password as being horribly insecure, seing as how you just typed it into an unknown web site with no reason to trust it.

To be fair, all the checks are running in JavaScript on your browser -- your passphrase never leaves your computer. Feel free to packet-sniff to verify :-)

Until the author decides to change it to send the passphrases to the server, or someone MITM you and injects code to do the same thing.

Basically, it's a bad idea to start typing passphrases into an untrusted, unencrypted web page, regardless of whether it does anything bad right now.

But you could change that, and you're hosting it on non-SSL, so an attacker could change that too.

Recommendation to you: Just put the code up on github and share that instead. It's static, so you can even host it on a github page. Write a readme that makes it obvious that this is just a technology demo and not a for-real online password checker.

Because sadly people here are too dumb to just 1. read your totally readable javascript source or 2. wget the code and try it out for themselves in a local sandbox (if they are really that worried about MITM). I guess it's way easier to just dash off some negative comment about something that's not even a problem in the first place.

Yup, check out https://github.com/lsb/passphrase-safety-ui

To be fair, all the checks are running in JavaScript on your browser -- your passphrase never leaves your computer.

What's to prevent, e.g., a browser extension from listening in?

What's to prevent a browser extension from listening in on any password?

Don't install stuff you don't trust.

What's to prevent a browser extension from listening in on any password? Don't install stuff you don't trust.

I didn't mean to imply otherwise; merely that the author shouldn't claim that their site is 100% safe just because it's Javascript running in the browser.

By the time the packet sniffer says that my password has been compromised, it's too late to do anything about it. I suppose I could come up with a new password, test it while watching for no network traffic, and if there was none then go ahead and use the password. I'd rather teach people not to type their passwords into random web sites, though.

> More seriously, it should simply mark every password as being horribly insecure, seing as how you just typed it into an unknown web site with no reason to trust it.

That’s what this password checker does: http://www.inutile.ens.fr/estatis/password-security-checker/. (Original discussion: http://news.ycombinator.com/item?id=4075842)

Precisely the one I was thinking of. I love that page.

To implement this space-efficiently, I wrote a compressed bloom filter: http://github.com/lsb/gcs

It's more space efficient than a standard bloom filter, runs in constant memory on the server, and has pretty fast performance in Javascript in browsers too.

Check out the description of a Golomb-compressed sequence at http://algo2.iti.kit.edu/singler/publications/cacheefficient...

I'm not sure what exactly the page does... It seems to me like a word gets greener if it's longer... What exactly does the algorithm do to computer the color?

Clicking on the word gives you more info. Blue = not found in GBooks 1grams. Green = high-entropy word. Red = very low-entropy word (<10 bits in a 1gram model). Orange = low-entropy word (<8 bits in a 2gram or 3gram model).

Can we all please read at least a reasonable portion of the comments before repeating some form of "its insecure because its in the browser!"? Upvote one of the existing comments if you think that's important to talk about here. Yes, there are potential issues with that, and yes it would be wise to instead download the code, peruse it, and then run it locally if satisfied with its security. Now that that's over with, can we talk about some of the interesting aspects of the post?

Have others tried programming a project in one language and transcribing it to another? I work with a fair number of languages, and I find myself falling into a distinctive mindset with each one. Several of the nice idioms I use in one language don't seem like they'd translate well to another. Beyond being an interesting exercise in the mindset behind both languages, are there any benefits to this? It seems like you'd have to cut features you might normally use in the source language until you've reached a union with features from the destination language. It seems like that'd be a pretty tough transition going from a typed and functional language like Haskell to JS.

(1) Write webpage for people to 'safely' type their passwords in.

(2) Replace Javascript

(3) Profit!

(Bonus: Give iffy password advice at the same time— "correct horse stapler battery" is only good if you're sure the attacker can't do a billion net-attempts per second. ... this tool tells you a random 128 bit long sequence of "a" "time" is insecure)

A similar project was release by Dropbox a while back (zxcvbn): https://dl.dropbox.com/u/209/zxcvbn/test/index.html

That looks pretty cool. It seems that it's only single words, not phrases, so you wouldn't catch that adding "man" at the end of "One small step for" doesn't help the entropy of your passphrase.

Are you expecting people to disclose their passphrase to a third party ?

The idea is probably not so bad but the browser is really not the place to run these kind of experiments.

There's no third party! It's all in your browser.

You download basically a few bloom filters for low-entropy 1-grams, 2-grams, and 3-grams, and there's some highly optimized Javascript to do probabilistic matches.

Well, as far as I'm concerned I have to trust that this form won't POST my passphrase to a server you own.

No personal offense intended, that is a genuine problem with your approach.

Yeah, my first thought was "...collecting the shasums and md5sums?"

collect the plaintext!

I was thinking about creating an Android app with 0 network permissions to do exactly this, but didn't get around to it.

Once you've loaded all the 3-grams (~50MB of data), you can run entirely offline, close the page, and then go back online.

Can Android apps without network permissions open pages in the browser? If so, there's one way.

View in Chrome, hit F12, click "Network". Put some random stuff in the form and click the button. Witness the chirping of crickets.

Then try your password.

Alternate solution: load the web page and then turn off your WiFi while you test it.

Its for fun. Way to over-think it.

When testing these kind of experiments I always use a similar password (with similar structure, completely different components and order of components)

12345 => green

password => green

Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo => green

"eight six seven five three oh nine" => green

Yeah, the word list is from Google Books, which isn't exactly as colloquial as people are with passphrases / passwords.

Ideally v2 gets trained on blog posts / tweets / other colloquial text sources.

I don't see how 3rd and 4th examples aren't superior to green.

"buffalo buffalo buffalo buffalo buffalo buffalo" is a well-known phrase (meaning that buffalo [animals] from Buffalo [place] fool [buffalo as a verb] other buffalo from Buffalo).

"eight six…" are lyrics from a popular song (a.k.a. “Jenny”).

Four common words may have more entropy and that is helpful against a brute force attack but what about a dictionary attack. There are just about as many combinations of characters in a 10-12 character password as there are combinations of four English words.

I think the thing is that very few non-generated 10-12 char passwords are actually random - they tend to consist of words with simple replacements anyway. So why not use four random English words?

This comes up a lot in the bitcoin world where people think it is neat that they could use a pass phrase as their private key to their wallet.

It's actually incredibly dumb, if the attacker knows you are using a pass phrase then a dictionary attack is about as effective as a brute force attack. And in the case of bitcoin wallets, even a pass phrase with 12 dictionary words has substantially less entropy than a random key.

You could of course use 3 instead of e and do other unusual things, but all that stuff reduces the memorability of the phrase while gaining you less than you think in terms of entropy.

If you want entropy in your passwords or phrases, and you do even if you don't realise it, then you need them to be random.

User friendly key management is the real problem in online security, something that is secure and simple enough for the average senior to understand and use could make a ton of money.

>even a pass phrase with 12 dictionary words has substantially less entropy than a random key

Actually, 12 random dictionary words is incredibly secure. If you choose 12 random words from a pool of 100k words, then your entropy is:

100000^12 == 10^60 =~ 2^200

In other words, 200 bits of entropy. It would take an attacker longer than the history of the history of Earth just to count to 2^200. So, even if an attacker knew that your password was 12 random english words, they're never gonna crack it using brute force.

Interesting tool. The concept of high entropy from passphrases rather than passwords will be very useful for deterministic Bitcoin wallets (see https://en.bitcoin.it/wiki/Deterministic_wallet).

Text box hung (cursor disappeared), then browser hung, then had to kill the process. IE 9.0.8112

It gives misleading results in that:

"password" shows in green

"1234" shows in green

"hello world" shows "hello" in green and "world" in yellow

so while you're able to calculate the entropy, it missed out on the fact that some high entropic words are still bad choices.

Seems like it's got some issues "whattheeverlovingshitfuck" seems like a highly secure password yet it told me it wasn't.

1) If you break each word apart, it looks like a false positive for "fuck" being low-entropy, based on "loving" "shit". Click each word to see.

2) It just said it's not in the dictionary. I'm admittedly not doing segmentation, so that's a deficiency.

dis-envowelment probably produces better entropy that will never match a rainbow table (until they catch on)

bad: once upon a time

good: nc pn tm

(though you obviously want longer words)

In reality you are better off creating nonsense words.

Yeah, "arglebargle babelfish supercalifragilisticexpialidocious" is better than "i love you".

However, the goal is to memorize it, or otherwise record it, in the end, so you don't want to get stuck typing in nonsense words, because then it's the same problem as Tr0ub4dor&3 .

Yes but even a single character replacement will break rainbows.

I mean "un1corn" vs "unicorn"

A month later: "Was it 'un1corn' or 'unic0rn'?".

> (until they catch on)

Assume they already have.

Crackers do implement common patterns & substitutions.

And even if they don’t yet, your password could be cracked in 10 years to gain access to an account you never updated or data you forgot about…

LastPass, LastPass, LastPass.

Or 1Password, or whatever. But something. Please.

Reply on news.ycombinator.com