Limiting passwords to 12 characters is "secure enough" | Hacker News Reader

Limiting passwords to 12 characters is "secure enough"

forums.stardock.com

97 pointsJayschwa104 comments

If a 12-char password is "secure enough" today, then a 16-char password is obviously even more secure and future-proof. Not to mention a 30-char password, or a password that contains more special characters than what your dumb webapp allows.

Not to mention that a 30-char purely alphabetic passphrase such as xkcd.com/936 is so much easier to remember (i.e. less likely to be written on a post-it note) and type into today's mobile devices (i.e. more likely to log out properly, because it's easier to log in the next time) than a 12-char password with two numbers and one symbol in it. What I'm trying to say is that there is more to password strength than the time it takes for a botnet to brute-force it. Humans are the weakest link in most security systems. If you want strong security, you need to design your system so that humans can interact with it without too much mental strain.

Nowadays, anything less than [\x20-\xFE]{8,64} is just a lame excuse for storing passwords in a plain-text VARCHAR field without proper escaping. Therefore, if your password policy as any more restrictive than [\x20-\xFE]{8,64}, I'm going to assume that you store my passwords in a plain-text VARCHAR field without proper escaping.

I don't see why you should limit the length of a password.

Exactly. In any way in fact. A special char password of 8 char is not more secure than a a-z phrase of 20 long.

I think there is some sense in having a lower limit around 6-8 chars. No matter how many special characters you use, it won't be strong if it's too short.

The upper limit of 64 chars is just something that I copy-and-pasted from an actual web app that I wrote some time ago. It works in most cases, but if I were to write the same app now, I'd probably remove the upper limit or make it very large. (By the way, bcrypt only hashes the first 72 bytes of your password [1], so make sure to do something like bcrypt(sha256(password)) if you plan on using longer passwords.)

[1] http://news.ycombinator.com/item?id=4515894

>Therefore, if your password policy as any more restrictive than [\x20-\xFE]{8,64}, I'm going to assume that you store my passwords in a plain-text VARCHAR field without proper escaping.

Alternative interpretation: the Website is neither UTF8-safe (or whatever charset you prefer) nor are prepared statements used. Otherwise VARCHAR is fine even without any escaping.

Sorry, that was supposed to be \x7E but I can't edit anymore. Now you only need to deal with printable ASCII characters.

No problem, I was assuming printable anyway... ;)

I just wanted to point out that it's possible to use VARCHAR even with weird characters.

Here are two real world issues that could arise

http://vbuterin.blogspot.ca/2011/08/password-strength-rebutt...

I think some cryptographers and security people have given rebuttals as well but I can't find them at the moment.

Interesting, but I think the author is focusing too much on the desktop experience. Try typing 'Tr0ub4dor&3' vs. 'correct horse battery staple' on a phone. Having to shift between alternate layouts every other character is not only annoying but also makes you prone to forget which character you were trying to type. With a full-size keyboard, on the other hand, you can rely on muscle memory to get it right without even thinking. As for shoulder surfing, I find it rather difficult to shoulder-surf someone who is typing on a glossy 4-inch screen, and you can always choose unusual words/spellings to throw off people who try to guess. Corrupt hearse buttery scalpels!

I agree that it would be a better system for phones. I'm not sure about full size keyboards. Muscle memory will allow you to learn the password with only simple characters more quickly but eventually both will be learned. Then the only factor that matters is how accurately the user can type. I don't think muscle memory could ever get 100% accuracy for typing one character correctly. Anything less than 100% and longer passwords will be worse. If you type a key correctly 99.9% of the time then you will lose about twice as much of your time to wrong password entries with an 11 vs 20 char password.

> Here are two real world issues that could arise

Definitely true.

On the other hand, non-tech folks often don't even make an attempt to remember password an put them on sticky notes in front of the screen. (At it can still get worse...) I think for these people long alphanumeric passwords are the best.

As I see it, character limits aren't so much about security, as just a dumb way to be hostile to the user. All of my passwords are site-specific unique passwords generated by a password manager. I don't care if you store plain-text passwords, because if someone steals passwords out of your database then they already have all the access that my password to your site would've given.

But if a site rejects the password that my password manager generated (16 chars [a-zA-Z0-9]), then I have to work around it, make a password manually, and it's generally a pain in the ass that shouldn't be necessary. And since I'm doing it right and these sites doing it wrong, I'm not inclined to be forgiving.

The worst thing is when password boxes have paste protection so site-specific randomly generated passwords become a pain to use. A few sites have started doing it recently, it's nonsensical.

Thankfully good browser password manager extensions (I use 1Password) ignore all of this nonsense.

$("#input[type='password']").val("secret");

Isn't there research out there that proves long sentences and phrases are better than any random alpha numeric password

Do I get to cite this http://xkcd.com/936/

Well, you obviously have to define "long" and "any" in that sentence. The famous xkcd cartoon evaluates a four word "phrase" (four common random words) as 44 bits of entropy. But he's not comparing it to a random alpha-numeric string, he's comparing it to taking an uncommon word and doing a couple of letter substitutions to defeat complexity requirements.

A real random alpha-numeric password (what I get my password manager to generate, since I don't have to remember it) 12 characters long is more like 70 bits of entropy. You'd need 6 random words to match that. Essentially for every 2 random alphanumeric characters you need another random word.

No. And preliminary research suggests that they are easier to crack.

http://arstechnica.com/security/2013/01/grammar-badness-make...

Legitimately randomly generated passwords still win, as long as the server uses a salt with bcrypt or iterated hashing like PBKDF1 or PBKDF2.

Properly chosen pass phrases are very strong.

Most people cannot properly chose a pass phrase.

Use something like Diceware to generate a phrase.

If you read 128 bits of data from /dev/urandom, and then map the result to a space of 2128 possible passwords, then it doesn't actually matter what the possible passwords are, as long as it's a one-to-one mapping.

> if someone steals passwords out of your database then they already have all the access that my password to your site would've given

I see where you are coming from, however this premise is fatally flawed.

If my password is stored in plain text then an attacker needs only to read just my password and they have access to my account.

If the site is susceptible to SQL injection attacks it is perfectly reasonable that they can extract my password without having access to any other part of the database or system.

Another example is gaining access to an offline backup, archive, etc.

"But if a site rejects the password that my password manager generated (16 chars [a-zA-Z0-9])...it's generally a pain in the ass"

No, that just means your password manager sucks and is out of touch with the real world. Any good password manager lets you quickly generate passwords of any length.

Ah, yes, there's nothing quite like a condescending representative entirely out of his depth telling you to "do the maths" to show your customers that you really care about their security and privacy. I wish you good luck in getting them to listen to you.

While the password limit raises some concerns, this ^ is exactly what I took away from the exchange. Brilliant support!

That entire thread was cringe-worthy. At least the last company I reported something similar to came back with "our developers are looking into the problem, and we will probably switch out the login scheme in the next few weeks". Whether they actually did it or not, who knows, but at least they acknowledged it.

I like the way that he implies that you don't have the right to complain about the 12-character limit at Stardock unless you complain to your bank about the 4-digit credit card pin limitation first.

This is far from the worst offender.

Banks are typically the worst. All sorts of gimmicky password requirements. 8-12 characters. Must have one capital letter. Must have one number. No special symbols.

So "I can't believe it's not butter!" won't work, yet that would probably be a pretty secure password, and be entirely rememberable. In fact I could come up with a silly pun-filled sentence for each site I visit and make passwords fun again.

My favorite is the eAPIS password requirements:

https://eapis.cbp.dhs.gov/help.html#a7

   Your password:

   must start with a number and be between eight and twelve characters in length, and
   must contain at least one of the following special characters:
   Cannot include your Sender ID, and
   Cannot repeat any character consecutively more than two times.

That would make an excellent passphrase

It's funny that the descriptions of password requirements would make much stronger passwords than any password a reasonable person would ever use.

The poor state of bank passwords is fresh in my head from working on taxes tonight. It's kinda sad that the message boards I use for non-sense are probably more secure than my banks with respect to password handling.

That said, I don't think Stardock gets a free pass just because a lot of banks suck at it.

Nobody gets a free pass. Didn't mean to imply that. They all suck, it's just a matter of venting :)

American Express used to require 6-8 alphanumerics. No more, no less. Fortunately they've upped this to... I think something like 20 characters.

Look, I get that there are other safety factors (I pray) in place to prevent someone from hacking my account (most commonly in the form of login-attempt limits), but that's absolutely no reason to stop me from making my password longer and more complex. If I want my door to have a deadbolt _and_ a chain lock I expect a damn good explanation if someone tells me I can't.

Even if they were brute-forcing, a new GPU cluster can do 350 billion guesses per second. http://arstechnica.com/security/2012/12/25-gpu-cluster-crack... That means an average of 78 days to crack an individual password, even with no heuristics about which passwords are more likely.

The first step is to convince them that the database is not actually failsafe if even companies like Linkedin can't do it. Then convince them that it matters if the password leaks (you should use unique ones anyway, but everyone knows that not everyone does). Only then this kind of offline brute-forcing is an argument.

When I complained to my bank about their 12 character limit they told me...

"12 characters is already hard enough to remember."

Sigh.

I would have just responded - "You know 'Lord of the rings' the movie, right? The title of that movie is a 17 character password. Is that hard to remember?"

It is kinda hard to remember if you need to pepper it with numbers and special characters to comply with the bank's rules.

    L0rd_ofthe$Ring5

Get a whole heap of passwords from random.org. Create a text file with the sites you use with the usernames/passwords. PGP Encrypt the whole ensamble with a good strong password. The only one you really need to remember.

Forget your password? Once you reset via email, as soon as you get access to that encrypted file, get a new random password and reset it again. Save the new password in the encrypted file.

Password managers often connect to the internet to retrieve your passwords so if you lose your access, you're SOL. I also wouldn't trust a browser plugin as that may be prone to compromise. Backup to your laptop or something if you need to take it with you, but keep it encrypted until needed.

Forget the password to the encrypted text file? Throw your life away and start a new identity.

Edit: Pointed out below (and I agree whole-heartedly) use /dev/u(a)random

And idupree's points are spot on.

> Forget the password to the encrypted text file? Throw your life away and start a new identity.

Singularity Amnesia?

> Get a whole heap of passwords from random.org.

I suggest /dev/random or /dev/urandom, as it doesn't involve a third-party. You can xor with data from random.org, if that makes you feel better.

> Forget the password to the encrypted text file? Throw your life away and start a new identity.

Just print out the plaintext of your password text file, and store the piece of paper somewhere reasonably secure. I say `reasonably' because if someone were to gain physical access to your computer, they could install a keyboard logger anyway.

I'm not too fond of printing out passwords. If I forget, and I'm extremely forgetful, that's just a disaster waiting to happen. I know my brain and I know it can't be trusted with physical security. Also, I'd rather use /dev/urandom instead of simply /dev/random.

Considering my aversion to using a stranger's computer to login to my accounts and the fact that I never use an open WiFi connection for anything without Tor, I'm much happier using a local copy of the encrypted file or at the very least a secure offline mirror(s) to download a copy of the encrypted file if I don't have it handy.

Not really the issue, but /dev/urandom is weaker than /dev/random, it is urandom which never blocks (try "hd /dev/random" and note that it blocks, then jiggle your mouse a bit and it will come back to life)

This is true on some systems, but not others. On FreeBSD (and OSX, as I remember) /dev/random and /dev/urandom act identically. The underlying CSPRNG, Yarrow, is designed to recover from a compromised state vector. Unfortunately, Yarrow relies on entropy estimates to time its re-seeding.

I've said it before: entropy estimates are a fiction. Ideally, /dev/random and /dev/urandom would both offer non-blocking access to an underlying Fortuna implementation (using a cryptographic hash function instead of a cipher, to avoid export/import restrictions).

Using PGP sounds fine, but why trust a random (ha) website more than you trust a browser plugin?

Even though you generated a bunch (up to 100), what is to stop random.org from storing every one of those? Much better to just use pwgen or similar.

1Password allows you to sync the encrypted file via dropbox, so if you lose your access you'll still have the encrypted file, you just won't have any updates. And if you can't trust the browser plugin, you can't trust your browser either and no password scheme will help.

  | And if you can't trust the browser plugin, you
  | can't trust your browser either

Depends. Adding plugins extends the attack surface area. Also, the plugin author(s) may not be as diligent at stamping out bugs/security holes as the browser developer(s).

(my tinfoil hat mode: I don't even have any important secrets but I believe in knowing how to protect them)

Use /dev/urandom, not a website. Make sure you have configured your text editor not to automatically save any backup files, cut buffers, or the like, and never write it to disk in unencrypted form. (I use vim >= 7.3 and its blowfish encryption; see encryptedvimrc and random_alnum in my scripts https://github.com/idupree/scripts ) If you copy/paste passwords, make sure you don't have a clipboard manager that persists recent history to disk. Also, encrypt your filesystem in case you screw up on any of the above. If you have swap, make sure that's encrypted with a generated-per-boot-from-urandom key generated after loading last boot's stored entropy from the disk. (A dedicated password-managing program might do some of these things for you. I haven't looked into their security methods yet; have you?)

If you can, use an email provider for your acct-registrations that uses decent security practices; use a high-entropy password for it; use different email addresses for every site, to make it harder for social engineering attacks (someone calling, say, Amazon or Apple's call center pretending to be you). The latter is probably hard unless you use your own domain or think '+' addresses are sufficient. If you use your own domain, you're vulnerable to your registrar or your account with them or your DNS being compromised, but you should have rigorous passwords and good registrars here because losing your domain name stinks. If malware gets on your computer, it can watch you and steal your passwords, so keep your system and browser up-to-date with security updates, disable riskier parts of your system that you can live without, prefer OSes/systems that are more on top of their security, and don't make enemies.

I don't understand why password managers like OnePass store passwords online; everything else they're doing as browser plugins is fighting the good fight. (True, there are risks of giving the browser the ability to access your passwords at all; but they're probably less than the risks of password reuse and low password entropy, and greater convenience means more people will use the system for more sites. Firefox Sync is the only consumer-friendly online storage that I've seen and consider well-engineered-&-documented enough to consider trusting. Tarsnap and Tahoe-LAFS also meet everything but the "consumer-friendly" bit there, and have a somewhat different focus. It may be worth considering encrypted online mirrors legitimate (online mirrors, not sole copies) for the sake of people who don't do backups, have multiple devices, and/or have their disk fail or device stolen.).

I think you mean LastPass or 1Password.

Startup idea: the email equivalent of 1Password.

You give each site a completely unique, distinct yet valid email address. They forward to your real email address and vice versa.

This way if one email is compromised you know where the spam is coming from plus it reduces email tracking and correlation.

At least the last time I used it, Google Checkout had an opt-in feature that would create a unique unguessable email address the first time you purchased something from a shop, and this email address would be proxied to your GMail account.

While that is nice, I was thinking of a more distributed model (not necessarily hosted by Google)

I've been using a 50-ish line Python script for a bit more than a decade. It generates a password from /dev/urandom on Linux/OSX and the system crypto random source on Windows. It pipes the output to gpg, so the password doesn't go through the clipboard and isn't visible in ps output.

Here's the version I updated to Python 3 a year or three ago: http://pastebin.com/RusCWm5Q

Usage: create_pass [<username>] <email_address> <site_name>

Example: create_pass kmag kmag@example.com news.ycombinator.com

    gpg -d ~/Crypto/Passwords/news.ycombinator.com.gpg

Edit: part of me hopes that someone is still grinding away at my 80-bit stolen Linkedin password hash. I of course generated a new 80-bit password.

Stardock deleted the thread after it started to get some attention. Here is a partial screen capture: http://i.imgur.com/R5gs8HC.png

Unfortunately, it's missing some of the newer (and frankly, ignorant and cavalier) replies from their tech support guy.

Reading comments in this thread have been very enlightening. I am wondering if there is a best practices or guidelines for password storage for web service operators.

I currently manage a web service that has about 1,000 registered users. I have taken the most restrictive path to storing password in database except I need to make sure user/password database is portable from one host to another. Reading the comments, I am getting the impression that such portability may not be a good thing. But then how can I migrate from one host to another or restore backups?

Are there documented good practices for storing passwords in database that also allow portability.

Simple rules for the bare minimum

- never store plain text password - never store direct hash of password - use a salt (must be stored) and hash password and salt

Ideally salt and hash of password/salt are in different databases.

Avoiding MD5 is recommended, but if you are at the point of worrying about that, you have bigger issues.

I agree with everything you said except the "store in two different databases" line. If someone has compromised your system responsible for handling authentication then presumably they'd have access to both databases regardless - unless you've designed some kind of complex API for generating the salt and secured that API behind a whole different set of security and authentication (which almost everyone is too lazy to do).

The salt is just there to stop rainbow tables being generated, and if you're really evil to add computational overhead, it isn't meant to be used in a game of hide and seek.

Here's one http://codahale.com/how-to-safely-store-a-password/

I'm not sure what portability issue you're referring to.

You should become familiar with the Open Web Application Security Project https://www.owasp.org/ , who are working on all kinds of best practices for web apps.

OWASP has a draft on password storage https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet and also one on password complexity https://www.owasp.org/index.php/Password_length_%26_complexi... .

They have plenty more, like guides on common security vulnerabilities, etc.

I'm not so sure anymore about the password length limitations (or any other weird password requirements for that matter).

For the longest time I was wondering why my bank would ONLY allow a 5 digit password, alphanumerical only and it MUST contain at least one letter as well as one number, while they let you choose your own username completely free of any restrictions, including special characters. After thinking about it for quite some time, I remembered all these sites where your password had to be as least 6 characters (now 8 seems to be a general minimum).

By forcing users to use EXACTLY 5 characters at least you cannot use the SAME password your already using for your mail and whatnot, except for the fact that there is nothing preventing your from simply dropping the last character (but you sure would NEVER do that, would you ;-), assuming of course you already have letters as well as numbers within the first 5 characters.

While 5 characters seems extremely weak, If you get it wrong 3 times, your account is locked. Locked as in "you have to call them and identify yourself with A LOT OF DETAILS about your account and transactions" to unlock it and reset your password.

I have no idea how they store passwords and it doesn't really matter to me, while it probably should. They are a BANK and if they get hacked and their customer password database gets compromised, I am sure they will have worse problems to take care of.

What I would really like to see is their evaluation of security versus added support work for locked accounts.

Maybe that's their goal. But if a password has very strict requirements, I cannot choose my own password. This means I cannot remember it, which is annoying in itself even if there are no consequences for security (I need to write it down, reset it every so often, or call them to unlock my account -- a lot of effort).

The result is that a customer of their service is annoyed. I think a login/signup procedure that makes people happy instead of annoy them should be worth a lot to any brand.

You are incorrect. The policy is that users get locked out after 3 attempts... until attackers get smart enough to bruit force through the usernames, 3 wrong passwords each.

80% of the customers getting locked out of their bank accounts at 5 PM on a Friday only happens once before the bank changes policies to something that allows the attackers to perform a rate-limited attack on the 5-character passwords. The new lockout policy goes into effect before the bank can force everyone to upgrade their passwords.

GAME OVER

They deleted the topic. Nice way to treat your customers...

Skype Passwordlimit: 12 Charakters. Windows Live Passwordlimit: 16 Charakters. Paypal Passwordlimit: 20 Charakters. It's stupid to put this limit on passwordinputs that should get hashed anyways. Twitter, Facebook, Google Password Limit: >100 Charakters.

Added a rather lengthy comment, hopefully convincing them a bit. Let me know if I should edit anything! My username there is the same as here.

http://forums.stardock.com/439802/page/1/#3315302

In theory it is secure enough - you should not be allowing a password attempt every second on an account and unlimited attempts per day per account.

But of course we should be using pass-sentences by now.

> I'm not concerned that someone is going to brute-force my password

Please read the article before commenting. The OP's concern is that all of the passwords are sitting in plaintext in a questionably-secure database somewhere.

I stand corrected, there is absolutely no excuse for plaintext passwords.

Bill Cheswick, of the "Firewalls and Internet Security; Repelling the Wily Hacker" fame, gives a great talk called "Rethinking Passwords" calling for a better solution:

http://www.youtube.com/watch?v=KRVRlhrLKkI [video, 22 min] http://web.cheswick.com/ches/talks/rethink.pdf [slides]

I blogged about week ago: Some funny stuff for a change: I told my colleagues that we receive at least 5000 "hack attempts" aka failed logins daily to any of our public Internet facing servers. One of my colleagues just said to me: "Well, you're having such a password policy, that maybe those are actually failed login attempts and not hack attempts at all." - It really got me laughing. Yes, passwords, especially long complex and random ones are painful for users. Here's password of the day (opening and closing quotes aren't included in the password):"^j'lb#K-€3,<_úgWJdXå(n_6=41Bµ%cj!" Btw. Good luck guessing the password or finding it out using SHA-1 hashs or so. I know it's possible, it just might take a while. ;) p.s. This password still got less than 256 bits of entropy. I never really intented anyone to actually remember the passwords. I personally consider passwords as "shared secret", which is just a blob of random bits.

The fact that you can see the passwords is a bit worrying.

Passwords have been compromised before by being captured in server logs that ended up being accessible.

If you are logging failed password attempts anywhere, then you've got a security hole.

Here's the details on the breach I'm talking about http://ieeelog.com/

What about 5 characters? Saw this today on a product that claims "We use advanced technology in a security–rich environment"

https://twitter.com/humbit/status/297417037989429248/photo/1

I've seen worse. There's a UK company called The Train Line ( http://www.thetrainline.com/ ) that handles money, and limits passwords to 10 chars with no punctuation characters.

I don't understand why you are so upset. Just edit the HTML and set maxlength to anything you want. It will seal a deal. :D

As far as I can tell, it's checked on the server side too. But I might have another go at it tonight to be sure. The worst that could happen is that I get a longer, more secure password ;)

The worst that can happen when you mess with form field lengths: no validation on entry to the database, but validation later when pulling it out to check it, so you're now locked out of your account.

Interesting, I didn't know that. So the worst that could happen is that I'd be locked out of their horribly insecure site and forced to use something better. I don't re-use passwords, and I declined to let them store my credit card details, so when they get hax0red, I won't lose anything worth stealing.

It's possible the server will let you set the password to something longer than 12 characters but nott allow you to log-in with it. It's apparently happened on sites before.

Even "Microsoft Accounts" have a 16 character limit on their passwords.

..and now the thread has been deleted after some further criticism...

Here is a partial screen capture: http://i.imgur.com/R5gs8HC.png

Unfortunately, it's missing some of the newer (and frankly, ignorant and cavalier) replies from the tech support guy.

I've added a comment, please verify.

http://forums.stardock.com/439802/page/1/#3315287

Read it, seems good to me. I added a comment as well (not in response to you).

Security red flag: passwords are "secure enough."

Technically, if they are using bcrypt hashes with a high enough work factor, and salt then with something like UserID, then 12 characters is pretty damn secure even if their whole DB gets leaked.

Of course, there's no good reason to limit passwords to any length.

You are missing the same point they are. A hash doesn't care about the input length and produces a fixed size output. Consequently if Stardock are claiming there is a need for a limited input length then it is a very good "smell" they are not using hashing at all. The lack of hashing is the problem and debating acceptable length limits is avoiding the topic.

I've long used this smell to identify companies not to trust with security. It's rare that I would be willing to create an account somewhere just to buy something, but a policy like this is always a deal-breaker for me, because I would expect them to get hacked.

Another smell is bizarre rules. Rank amateurs are quickly spotted by requirements not to use various characters related to SQL injection and XSS. The other week I encountered a site that whined about consecutive letters, case and numbers. (My password was randomly generated by a password manager.)

Again, the point isn't about whether 12 is enough. It could have been 64 and the point would still stand. The OP's point is that limiting password length (to anything less than 1000 or so) is usually done to be able to set a maximum length on the password column of a database. Password hashes, on the other hand (including bcrypt), produce fixed-length hashes, regardless of the input size.

bcrypt has a 50 char limit. You could always prehash(sha256) the password before passing it to bcrypt.

That is not something I would have guessed about bcrypt. I learned something new today.

It's 72 actually. I thought it was 56 as mentioned on the original [?] BCrypt website[1]. A thread[2] on security/stackexchange discusses a workaround for the 72 char limit. See https://gist.github.com/4690368 for a simple test case that shows the >72 char truncation.

The source provides a hint:

    /* Schneier specifies a maximum key length of 56 bytes.
    * This ensures that every key bit affects every cipher
    * bit.  However, the subkeys can hold up to 72 bytes.
    * Warning: For normal blowfish encryption only 56 bytes
    * of the key affect all cipherbits.
    */

[1] http://bcrypt.sourceforge.net/

[2] http://security.stackexchange.com/questions/21524/bcrypts-72...

Passwords are bullshit. We should have a start-up about having a better way of keeping your digital identity other than hundreds of logins/passwords, but obviously everyone is too busy with figuring out better ways of sharing lolcats.

Not that lolcats are bad. They are good. It's just they aren't fun anymore once your identity is stolen. Or your mom's.

TechCrunch disrupt had a few solving this problem.

I'm sure they could use your support :-)

"better way of keeping your digital identity"

We'll get you a seared flesh barcode, for your birthday, on your forehead. Hands-free Facebook logins for life! Are you excited?

It's actually not very safe.

Startup? A for-profit company providing the service? No thank you, I trust my brain more than I trust anyone else be that person or a company. Or a non-profit organzation.

If your password is 100,000,000 characters long, that's simply a waste of bandwidth, CPU time, space on the disk * millions of users * 1000s of iterations = money flushed down the toilet. And remember web servers have timeout parameters spread across half a dozen config files. You're just asking for trouble. Not worth it. To protect one self-important nitwit's video game password? Even your million character password could be sniffed or worse, the attacker might offer a hot apple pie with ice cream.

that isn't the point. the point is if there is a limit on character length, its a clear indication that the passwords aren't being properly handled.

Let's see you implement it then smartypants. So you can learn the hard way why there is a limit. You think you're smarter than the biggest technology companies on the planet? It's a clear indication of nothing but your own little vendetta driving you crazy.

If you can't handle arbitrary-length strings, you pretty much don't know how to program. Really.

Any user input needs to be filtered, sanitized, validated and limited. Please be my guest and pass any user input to your magic hashing function, don't cry about it later because due to some special circumstances / framework bug / language bug / buffer overflow / extra hidden utf char, your magic function opens a huge security hole. oh oops.

Um what? If your hashing library hasn't been tested with a arbitrary sequences of bytes you have bigger problems than limiting user input to 12 characters.

Okay, fine. But why limit to 12 characters? My email address isn't limited to 12 characters when I sign up, and it's probably limited and validated too. The fact that something needs to be validated does not justify annoyingly strict limits. Allowing 64 characters is just as easy as 12.

Reply on news.ycombinator.com