Hacker News new | past | comments | ask | show | jobs | submit login
Wolfram Alpha's Secure Password Service (wolframalpha.com)
77 points by shawndumas on Oct 12, 2011 | hide | past | web | favorite | 37 comments

Their estimate of 100,000 passwords a second is a VAST underestimate of the capabilities of modern hardware and software.

For example: http://www.win.tue.nl/cccc/sha-1-challenge.html -- the winner is cracking SHA1'ed passwords at seven thousand times the speed WA uses in their estimates.

To be fair to Alpha, SHA1 is a really shitty password hash. (Use bcrypt, scrypt if you're feeling adventurous, or salted SHA1 with a configurable number of iterations if you really can't do better.)

Absolutely, but tons of places still use it (and md5 shudder), and you rarely know what hashing algorithm a place is using when you sign up. So when picking a "secure password" you should probably assume the worst.

You rarely even know if they store it in plan text.

If you're going to go the iterations route, instead of rolling your own, use PBKDF-2 which is documented in RFC-2898 and RFC-6070.

Is there documentation of best practices for using PBKDF2 as a password hashing function anywhere? I've switched to it as a more standard/better supported alternative to bcrypt, but information on this use case is worryingly scarce.

Even high-profile applications sometimes use weak password hashes. For example Windows passwords can be cracked at a rate of 8.27 billion password/sec on a Radeon HD 5970 graphics card, because the NTLM hashing algorithm is weak (simple raw MD4 hash of the Unicode password string). All Windows versions from NT4 to 2008 R2 are vulnerable.


Can't a service throttle the login attempts, though? Or are we talking about trying to reconstruct passwords from a stolen database?

"Secure"? Isn't "strong" a better adjective? If I tell you my password, it's no longer secure, despite still being strong.

Passwords need to die. Passphrases if you truly insist, but preferably Id like all sites to create new sessions by sending me an email with a temporary token.

Nice concept. How would you log in to your email, though? Surely you'd need a strong password? ;)

Ask for an SMS token. But don't ask me how you would turn your phone on. :)

I like pass-phrases, especially with non-dictionary words.

Try a pass-phrase with



Still a work in progress, I guess.

How do you log into your email then?

I'm no fan of passwords, but we can do a helluva lot better than that.

Such as? A temporary token through email is a slight inconvenience but I've yet to see a better method.

A different password on each site is unacceptable. Being locked into lastpass and the like is also unacceptable.

BrowserID means I can't use different browsers easily. Pass.

An email/token based solution means 1) Users do not have to go through a tedious registration process. 2) Users do not have to remember a passphrase (or worse, a password), which by the way is the most arrogant thing a site can require of its users. By requiring passwords you are telling your users that you're super-duper important and worthy of the memory space. You're not. 3) Logging in and signing up are now indistinguishable from the user perspective.

>BrowserID means I can't use different browsers easily. Pass.

BrowserID requires a single time email verification for a given browser, nothing precludes you from using it with multiple browsers. By definition, it's easier and less intensive than what you're proposing.

>A different password on each site is unacceptable. Being locked into lastpass and the like is also unacceptable.

I'm not locked into LastPass. There are alternatives and I could hack one together with minimal effort.

The other points you bring up have little to do with authentication and more to do with duplication of (often necessary) profile information. There are other solutions for that include extensions to OpenID and oAuth.

For if you really want a "secure" password sent over HTTP, I presume...

Sent over HTTP and generated on a remote machine, which could theoretically log it along with your IP. </paranoid>

Alternate ways of generating strong passwords on your local box that I'm aware of:

* Mac OS X users can launch Keychain Access, click the + button, then the Key button on the very right. This gives you a dialog window which will generate strong passwords in various configurations, such as memorable ones.

* The pwgen utility is available on several Linux distributions and on Macports. It too can generate memorable passwords. Check out the -s and -y command line options and note that you can give the desired password length on the command line.

Any other recommendations?

* apg http://www.adel.nursat.kz/apg/download.shtml generates per default pronounceable/memorable passwords. From the debian package description:

APG (Automated Password Generator) is the tool set for random password generation. It generates some random words of required type and prints them to standard output. Advantages:

  * Built-in ANSI X9.17 RNG (Random Number Generator)(CAST/SHA1)
  * Built-in password quality checking system (now it has support for Bloom
    filter for faster access)
  * Two Password Generation Algorithms:
     1. Pronounceable Password Generation Algorithm (according to NIST
        FIPS 181)
     2. Random Character Password Generation Algorithm with 35
        configurable modes of operation
  * Configurable password length parameters
  * Configurable amount of generated passwords
  * Ability to initialize RNG with user string
  * Support for /dev/random
  * Ability to crypt() generated passwords and print them as additional output.
  * Special parameters to use APG in script

At least they are embedded in images.

I would be more interested in generating pass-phrases like the "4 common word password" of XKCD.

Diceware (http://world.std.com/~reinhold/diceware.html) is one version. It should be easy enough to automate, if you can get enough randomness to pick each word.

shuf -n4 /usr/share/dict/words

http://passphra.se does exactly that =) Although it's sadly not https.

True, but there are two reasons for that! One is because I'm too cheap to pay the premium my web host demands for https. The other is because most of the entropy is calculated in your browser via Javascript (even borrowing a JS implementation of SHA-1). It's extremely unlikely that either I (the server), or a third party sniffing packets, could guess the passphrase you generated using passphra.se.

I've been using PasswordMaker for a long time. It creates new passwords for each site based on a master password and the url of the site. It has many other options as well. The advantage of PasswordMaker is that if you know the master password you can recreate the password for any site. If you lose your password with Wolfram you'll have to do some kind of reset/recovery. http://passwordmaker.org/

"Siri, generate me a strong password."

GLaDOSiri: "I've created a strong password, but you'll just write it on a sticky note left on your computer anyway."

"You monster."

mmmm ... You have a strong password but how you will remember it with a sticky note?

Some persons says that a pass phrase is safer password and it is indeed math true. However, currently most of the systems have catpchas or block out and brute force or dictionary attacks are no longer used.

One of the more effective methods is for example: you made a user in a weak page like a blog or something and then a someone break into a obtain a email account and the password for the blog.

Maybe if the hacker is smart enough he could try the email account with same password found and they got you. So, different passwords is the safest method you can lastpass, 1password, keepass to remember your password. They also allow to use multi-step security using OTP devices like yubi key or RDA token

I normaly use https://www.grc.com/passwords.htm when I need a random password

Does anybody know how the entropy is calculated?

ln(number of possible passwords)

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact