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.
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).
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.
When testing these kind of experiments I always use a similar password (with similar structure, completely different components and order of components)
(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)
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 .
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.
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.
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 :-)
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.
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.
"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”).
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.
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).
51 comments
[ 5.4 ms ] story [ 107 ms ] threadIt'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...
The idea is probably not so bad but the browser is really not the place to run these kind of experiments.
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.
No personal offense intended, that is a genuine problem with your approach.
Once you've loaded all the 3-grams (~50MB of data), you can run entirely offline, close the page, and then go back online.
Then try your password.
Alternate solution: load the web page and then turn off your WiFi while you test it.
(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)
bad: once upon a time
good: nc pn tm
(though you obviously want longer words)
In reality you are better off creating nonsense words.
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 .
I mean "un1corn" vs "unicorn"
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…
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.
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.
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.
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.
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.
What's to prevent, e.g., a browser extension from listening in?
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.
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)
password => green
Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo => green
"eight six seven five three oh nine" => green
Ideally v2 gets trained on blog posts / tweets / other colloquial text sources.
"eight six…" are lyrics from a popular song (a.k.a. “Jenny”).
2) It just said it's not in the dictionary. I'm admittedly not doing segmentation, so that's a deficiency.
"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.
Or 1Password, or whatever. But something. Please.
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.