What are the password limits?

[Enfaru]

I know this might be sensitive information, but to be honest I plan to max it out and I can't find them anywhere.

...and I really don't wanna have to find it out by trial and error.

So what I'd really like to know is:

1. What is the maximum length possible for a password
2. What characters can and cannot be used? I get standard numbers and letters can be used, but what about symbols...and alt-gr symbols and unicode symbols... Frisbeteria calls me paranoid, I like to think I live up to that.
3. If I asked whether the passwords are encrypted with at least SHA-2... would I get a confirmation?
4. What are the possibilities of using other languages for passwords...like Hebrew or Chinese characters?

I appreciate your time Administrator ^_^

[Enfaru]

Scratch that, I'll ask GHR... safer that way.

[Luna Amore]

Frisbeteria calls me paranoid

Scratch that, I'll ask GHR... safer that way.

Yeah, paranoid describes you well.

[Frisbeeteria]

Scratch that, I'll ask GHR... safer that way.

Admins don't read GHRs. That's for game mods.

1. I am unable to locate a technical limit on our passwords
2. AFAIK, there is no character limitation on passwords. Create a disposable puppet and test it if you like.
3. Stored passwords are encrypted. Mods (and probably admins) have no access to raw password information. I don't know our encryption method.
4. See #2 above.

[Enfaru]

>:) Thanks for the input, it's much appreciated.

[Unterhuld00003]

OMFG Awesome password support.

I mean, I haven't tested unicode.... but come on, 9.8KB password. Not nuthin gonna guess that. There's support for spaces, numbers, letters and all of the common symbols.

If Violet sees this. I'm converting to the Violet religion.

I had expected the password to just cut off after 1,000 or something, but I tested that and it it holds its own. .

[Reploid Productions]

OMFG Awesome password support.

I mean, I haven't tested unicode.... but come on, 9.8KB password. Not nuthin gonna guess that. There's support for spaces, numbers, letters and all of the common symbols.

If Violet sees this. I'm converting to the Violet religion.

I had expected the password to just cut off after 1,000 or something, but I tested that and it it holds its own. .

Password security, doin' it rite overkill.

[The Blaatschapen]

OMFG Awesome password support.

I mean, I haven't tested unicode.... but come on, 9.8KB password. Not nuthin gonna guess that. There's support for spaces, numbers, letters and all of the common symbols.

If Violet sees this. I'm converting to the Violet religion.

I had expected the password to just cut off after 1,000 or something, but I tested that and it it holds its own. .

http://xkcd.com/538/

[Victorious Decepticons]

OMFG Awesome password support.

I mean, I haven't tested unicode.... but come on, 9.8KB password.

Just make sure you never lose it. You'd never get back in, in a million years!

[Enfaru]

It'd be no use beating it out of me with a wrench I haven't the foggiest idea what the first letter/number/symbol it is. (But you're right, we nerds follow that ideology pretty strictly )

According to https://howsecureismypassword.net/ it would take "infinity" (never mind a million years, no matter how many calculations per second I add in) to break and considering the length of time it took me to create (3.231123432 seconds) I'm happy :3.

If I lose it, then I lose it, everything that I'm not prepared to sacrifice is backed up ^-^...passworded elsewhere using a different library. (That is to say, there's not a lot I'm not prepared to sacrifice).

[The Blaatschapen]

It'd be no use beating it out of me with a wrench I haven't the foggiest idea what the first letter/number/symbol it is. (But you're right, we nerds follow that ideology pretty strictly )

According to https://howsecureismypassword.net/ it would take "infinity" (never mind a million years, no matter how many calculations per second I add in) to break and considering the length of time it took me to create (3.231123432 seconds) I'm happy :3.

If I lose it, then I lose it, everything that I'm not prepared to sacrifice is backed up ^-^...passworded elsewhere using a different library. (That is to say, there's not a lot I'm not prepared to sacrifice).

Actually, I wonder if the hash on the server side is capable of having such a wide span of values. If it doesn't, then it might be a lot easier to crack it, by having another password match with the same hash

[Enfaru]

That's a reasonable assumption. However, 10,000 is a relatively smaller number in that sort of respect. Django had a problem last year (which has been fixed), but that was a problem with a Denial of Service attack rather than the password.

I can't find any evidence that a password could be too long especially for something like SHA-1 or SHA-2. (I mean, we're not using MD5 right...RIGHT!?????)

[Shadow Afforess]

OMFG Awesome password support.

I mean, I haven't tested unicode.... but come on, 9.8KB password. Not nuthin gonna guess that. There's support for spaces, numbers, letters and all of the common symbols.

If Violet sees this. I'm converting to the Violet religion.

I had expected the password to just cut off after 1,000 or something, but I tested that and it it holds its own. .

After a certain point, long passwords are meaningless (> 100 or so chars). I mean all a hacker has to do is find a hash collision for your password. If your password is 1000000 chars long, but "hello world" has the same md5/sha256/etc hash output, I can log in as you.

I too am curious about how passwords are hashed. That is the real key to the kingdom.

Further Reading:
http://en.wikipedia.org/wiki/Cryptograp ... h_function
http://en.wikipedia.org/wiki/Collision_ ... er_science)
http://en.wikipedia.org/wiki/Collision_attack

[Enfaru]

Lets see someone brute force that password though .

SHA1 should have a collision chance of about 1 in 2^160, SHA2 I suspect is somewhat bigger. I'm doing everything I can to make my password as secure as possible. Of course, this is doubled by the fact that I use unique passwords everywhere and change them every so often. So it's really down to the Administrator of the site that I'm using to use the best security they can grab a hold of.

I'm hoping that at the very least NationStates has upgraded to SHA-2 and uses (at least) RSA to encrypt its database with at least a 4096bit key... but that's just me hoping.

[Reploid Productions]

to encrypt its database with at least a 4096bit key... but that's just me hoping.

I can assure you with absolute certainty that our database is completely undefeatable.

Because it doesn't exist.

[Breadknife]

Lets see someone brute force that password though .

SHA1 should have a collision chance of about 1 in 2^160, SHA2 I suspect is somewhat bigger. I'm doing everything I can to make my password as secure as possible. Of course, this is doubled by the fact that I use unique passwords everywhere and change them every so often. So it's really down to the Administrator of the site that I'm using to use the best security they can grab a hold of.

Going back to the "Hello World" possibility, I can only say for sure (well, reasonably sure, trusting what I know about hashing algorithms) that "Gello World" won't hash-clash with it. But the chances of "Hello World" hash-clashing with one multimegabyte password is as likely as it hash-clashing with any other, and it's similarly as likely that "Gello World" would. Because, after a while, you get past the information limit of the hash involved and thus (in the most ideal hash, at least) the enumeration of every password below a given upper limit will have 'hit' every possible hash-result once and once only, and now they're doubling up.

(If they're not ideal, there are hash-results that still haven't been hit at this theoretical point, although that's only because doubling up has happened before that point, to delay the point of "full population". Although it's still not likely for "Hello World"/"Gello World".)

Also, not that I'm interested in doing the test myself, testing for "<A high number of characters>A" as a password and seeing if "<A high number of characters>B" will log you in (and increasing/decreasing the precursor by factors of two, perhaps, to try to find the limit) could also reveal if the hashing algorithm is even given the full password (also try "A..." against "B...", because the truncation could be FIFO as well), by the intermediary. (i.e. not even the hash algorithm's fault, which could continute to differentiate, but could be the httpd handler or even dictated as a spec-limit at the browser end.)


But without seeing any of the background code (as few people will, normally), I'm speculating. I'm not tempted to try to get the phpBB code myself and poke around (anyway I prefer Perl, to PHP, even though I can read and write both to one degree or another...), but of course any serious black/grey/white-hat will already have done that. For whatever purpose they intend.

[Enfaru]

I have tested <lotsofcharacters>A and <lostsofcharacters>B, the hash is applied consistently. If even one letter is wrong, the password fails. Of course, I can't say whether this continues after 10,000 but I can say that it works up to that point. There doesn't appear to be a limit as far as I can tell. Further testing would be required. You're right that the chance of a collision between hello-world and one multimegabyte password is just as likely as hello world clashing with gello world, fortunately, the chances of this are extremely damn small!

...Reploid... unless I'm completely misunderstanding you...

The password hashes need to be stored somewhere. Else, how the heck am I logging in? How are you verifying that the session cookie is for the right user? How do you know that you have X amount of nations?

Usually, it's because they're stored somewhere. Now it doesn't necessarily matter how you store them, typically it's in a ''designed'' database like mysql (is really freakin' common), but it could just as easily stored in a folder that has thousands of plaintext documents. Both of these in the literal sense are databases.

If the data isn't being stored somewhere...then clearly we have a paradox, because I'm confident that the information isn't stored on my machine. (Except a session cookie). Or maybe Reploid is just messing with my head, which is not out of the realms of possibilities (I'm going with 60% chance of screwing with me).

[Shadow Afforess]

Nationstates uses a flat-file database for nation and region information. I have even written a brief dispatch on my speculation of the game design, as supported by facts: https://www.nationstates.net/page=dispatch/id=239285

Feel free to contribute.

[Enfaru]

And here I thought Reploid was trying to make me delusional as well as paranoid . That's some interesting speculation that I'll be reading more thoroughly in a moment.

Still, proper encryption is a must. I've already noted that the passwords are encrypted somehow (Frisbeeteria I think), but there was no information as to how.

[Breadknife]

You're right that the chance of a collision between hello-world and one multimegabyte password is just as likely as hello world clashing with gello world, fortunately, the chances of this are extremely damn small!

Not quite what I said. If A="Hello World", B="Gello World", C=Very_Long_Randomised_Password() then the chance that Hash(A)=Hash(B) ought to be much, much less than Hash(A)=Hash(C). (By dint that a hash function that returns the same hash result from such a trivial one-letter-mutation would be considered horribly, horribly broken and wouldn't have lasted this long if someone had worked out it was doing it... A situation all kinds of people would be very interested in discovering.)

What I was saying was that Hash(A) could clash with Hash(C) (also Hash(D), where D≠Very_Long_Randomized_Password(), i.e. figuratively ending up with just one character changed from C, but certainly from somewhere else in the "Very_Long..." domain of passwords), and it's also not unlikely (though not simultaneous) that Hash(B) could clash with Hash(C) (or Hash(D), but again not simultaneously).

That's because however (by good luck or by good design, or probably both) a hash function works, it ultimately returns a given length of hash. For the best hash design, the absolute most different number of hash results (i.e. if you ask it to return hexadecimal digits, the number that relates to "0xFFFF....FFF" for the same number of 'F's as your indepedendent hash digits... plus one!) is the maximum number of distinct inputs you can have before a collision. (A worse hash functiondesign may never fully populate that "hash-space" with "things-that-give-that-hash-result".)

Anyway... Take the hash output and (again, in the best designs, but you may not get this happening) look at the number of different inputs that you can get out of it. Restricting passwords to uppercase/lowercase/digits, you can treat that as a base-66 number (almost, as it depends if/how you end up padding shorter passwords, when comparing with longer ones). Accepting the full gamut of the whole byte-range (even unicode/etc characters equate just to multi-byte definitions, and for now we'll ignore the possible impossibility of Char(127) and Char(0), among others, as valid inputs in their own right), that's a base-256 number.

If your hash result is two hex-digits long, that's 0x00 to 0xFF, or 256 possible outputs. The idealised hash function would run the gammut of Char(0)..Char(255) outputing a different number of this kind, and then as soon as it tried to hash two characters, would immediately output a hash result you've already seen.


So whatever the hash result is that is stored in the password file (I personally treat such flatfiles the same as a database, it's just a matter of the consulting functions, but I see what Reploid means about it not being a database), which could be treated as base-16 or base-66 or something else compatible with the format it is stored (thus somewhat lower in base number than base-256, for all intents and purposes), if you're using any and all characters available on the keyboard then once you're in the habit of using more characters in a password than the characters used to store the hash you're into the realms of guaranteed (even if unpredictable) collisions happening here, there and everywhere. "ABCDEFG12345678" wouldn't necessarily collide with any other sixteen-digit password used (assuming sixten digits of stored hash), but it would have any number of collisions, including many that are typable (e.g. "arandompassword?", hypothetically, but also awkward ones like "]R<£g|6_8~~;lF©a"). It's because you may have far more freedom in your password choice (not that everyone takes advantage of that freedom) of any given length than the hash would give.

However, it doesn't usually matter, because the hash (at least when hidden from the person trying to break it, who then has to use the guarded interface that can take stock of the number of attempts being tried and result in throttling down or even stopping altogether the attempts to try every possible password) still holds a vast number of 'boiled down passwords', well beyond the capability of a casual password cracker who doesn't have some sort of idea already and even a non-casual one would have to luck out (or the legitimate account user helps out by having used the likes of "abc123" or "password", perhaps) to get in before activating the alerts (hopefully monitored by someone, regularly) and/or countermeasures (e.g. auto-banning a given IP address for effectively DOSsing).


That was longer than I meant to write, and given I'm a little tired I've probably slipped up, somewhere. But I think the principle is sound, even if I've messed up in some of the detail.

And, semi-related: http://xkcd.com/936/