Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> That renders even the most secure password vulnerable to compute-intensive brute force

No it doesn't. My passwords are 30-character randomly generated and look like this:

    T7PN2m7Yju43IWtoBkwL6TLx18Rdyq
Do you want to guess how long it will take to bruteforce with that "monster"?

    (26 + 26 + 10)^30 = 5.91 × 10^53 possible combinations
At 348 billion guesses per second it will take

    1.53 × 10^42 seconds
or

    4.84 × 10^34 years
That's quite a bit longer than the age of the universe.


True, but in reality you're probably sending that password over something less secure (like an SSL connection) that doesn't require quite as long (but still a very long time) to crack.

Anything is only as secure as the weakest link in the chain.

If (I'm sure you don't) you allow your browser to save that password so that you don't have to enter it every time then you just need one cleverly designed trojan to be run on your machine (probably easier to do than waiting 4.84E34 years to crack a password) to grab the saved passwords cache from your browser and it's no longer secret.


There you go

30 chars password don't matter. Sure, it's not low hanging fruit, but it's not troublesome if you're the target

Why?

Weakness 1: Because it's written down somewhere. Weakness 2..n: weaker links in the chain


> Weakness 1: Because it's written down somewhere.

This should be part of your risk assessment. For most people and most passwords the risk is not someone riffling through your wallet to find the card with your 30 character password. The risk is from criminal gangs hacking a system and downloading a huge database of usernames / password hashes, and then performing an offline attack on those hashes.

For most people writing a good password down and keeping the password safely is better than using a weak password.


True

That´s why I use a 'throwaway' password for most unimportant accounts. Sure, may be easy to break, but it isn't logging in to my gmail.

Don't forget also the risk of getting locked out of your account.


I fell victim to that once, when I hadn't "upgraded" the re-used throwaway password I'd used to register to see what some random website was. When my throwaway password got exposed (in cleartext facepalm!) by PerlMonks, within a day or so someone had used it to send Acai Berry spam through my Twitter account (which 'd completely forgotten was still using a shared/throwaway password even though it had turned from "some random new website I was curious about" into "somewhere where I actually care about my online reputation").

Just don't re-used passwords _anywhere_ - choose a password generation/storage solution that works across all your devices, and use it to generate unique strong passwords for everything. (1PassWord + DropBox works great for me across my MacOSX, iOS, Android, and Windows devices - I occasionally would like it on Linux too, but rarely enough that I'm satisfied to use my phone and re-type passwords in Linux)


If Linux support is more important, LastPass works very nicely. Although using it on mobile devices is a 'premium' feature, at $1 per month.


Interesting. It is certainly needed to "upgrade" passwords sometimes.

My beef with 1PW is that it's a single point of failure, not to mention inconvenience/risks. For example, what if I need to check gmail in a trusted, but borrowed device.

The main issue I think is that using only one password for security is insufficient (but not necessarily go for a 2-factor auth)


On the "inconvenient/risks" point - yeah, security is pretty much always a trade-off between convenience and risk. I've already chosen two factor auth for gmail (and Amazon and Dropbox, and I'll add any other important service I can to that list when available), so I pretty much need access to one of my two phones or my iPad to run the TOPT token generator - and if I have any of those devices there's clearly no need to me to trust a borrowed device.

(Though in the complete disaster scenario, I have stored in my wallet, as suggested by Bruce Schenier, the app-password my phones use and the list of backup verification codes - unlabelled so a casual thief _probably_ won't know what to do with them... I've also got irregular exports of everything and the 1Password passphrase and phone PIN printed out and stored in an envelope in the office safe. I _think_ I'm sufficiently paranoid about all that...)


I don't see it as "single point of failure", at least not when your using Dropbox syncing - I've got versions of Dropbox running on two phones, an iPad, two laptops, my iMac, and my home theatre box. I've also got a copy of the data available from Dropbox's servers if I even need. (And there is a risk of a corruption to the synced-everywhere datafile propagating to all those places before it's noticed, but 4 of those copies are backed up with Time Machine (in two different physical locations), and Dropbox stores archived versions for me as well).


FYI, I've learned a little trick that 1Password doesn't seem to share widely. Go into your Dropbox, and in the 1Password.agilekeychain folder there is a file named 1Password.html. It's a read-only instance of your 1Password keychain usable in anything with a browser.


I think twitter nowadays is far from being an unimportant account.


Yeah, for sure - like I said, it's somewhere where I care about my reputation now. Back in '08 or '09 when the Perl Monks password got exposed, not so much (at least not for me...)


I store my passwords in KeePass, protected by one long password stored in my head.


Yes, there might be other attacks on the password, but rorr is responding directly to part of the article which claims

> Gosney’s system elevates password cracking to the next level, and effectively renders even the strongest passwords* protected with weaker encryption algorithms, like Microsoft’s LM and NTLM, obsolete.


> The National Institute of Standards and Technology (NIST) has issued a statement that says SSL certificates with a key length of 1,024 bits or fewer will be insufficient for security after December 31, 2010

> It is recommended that the algorithms and key sizes in the "Through 2030" row (e.g., 2048-bit RSA) should be used to provide the cryptographic protection

http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-P...

1024 bit is impossible to bruteforce. Simply incrementing an integer 2^1024 times will take more energy than our whole universe has.

Heck, even 128 bit would take 3.1×10^19 years to bruteforce with that GPU setup. My citibank.com uses a 256-bit connection.

SSL is not "less secure" than my 30-character password (correction: 128-bit one is a bit less secure, but 256-bit one is much more secure).

If it were, all the banks would be freaking out and would shut down their web interfaces.


RSA keys are composite numbers. Bruteforcing them involves factoring, not trying 2^n possibilities. A bruteforce of a 1024-bit RSA key possible to be published this decade and likely by 2030.

http://en.wikipedia.org/wiki/General_number_field_sieve


I think the suggestion of SSL being less secure was based on it possibly having some vulnerability or other (which, historically, has happened), not necessarily having to brute force it.

Hashes don't tend to have side-channel attacks.


Such passwords are certainly secure, but it's a pain to have to carry Keepass/other programs around when using other computers. I think I've found a happy medium by memorizing a simple password-generation function in my scripting language of choice. It produces sufficiently strong passwords, and if you're stranded without Keepass you can still generate them using a local interpreter or a site like codepad.org.


If you can sync your password safe aoftware to your phone, that pretty much solves that problem, at least for me.

(I also rely on having one of my phones or my iPad with me anytime I need secure access to any account of mine, 'cause I use two factor auth using TOTP tokens for places that support it like Google, Amazon, and Dropbox)


This doesn't work because there are conflicting rules out there about what a password should look like. Less than X chars, more than X chars, must contain certain chars, must'n contain certain chars...

I use KeePass, with a copy (via dropbox) on my smartphone for when I'm not at my own computer.


My bank actually limits passwords to a maximum of 10 characters. Drives me bonkers because it prohibits my normal use of the Stanford PwdHash. Many other sites have "helpful" rules that get in the way as well. Frustrating.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

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

Search: