Must be between 6 and 16 characters long

>Must be between 6 and 16 characters long

Why is there upper limit? What does it matter Rito, are you storing your passwords in plain text?

Other urls found in this thread:

security.stackexchange.com/questions/17949/why-are-passwords-limited-to-16-characters
blogs.dropbox.com/tech/2016/09/how-dropbox-securely-stores-your-passwords/
twitter.com/AnonBabble

>LoL
Lol

If the character limit is 16 for passwords it's a 99,9% chance of it being store in plain text.

A lot of db / web designers (read php ultra self educated to be engineers):
hur dur what is:
>Unicode support
anybody who uses weird letters doesn't belong here
>variable length
and to add another variable into my best(tm) code? are you mad?
>maximum length
the default one surely has to be larger than 16(tm)
>16
16 KB RAM should be more than enough

So in reality it all goes to the lazy dev. When all you need to do is to install somewhat capable rdbms which allows something like nvarchar2(maxlength) and then you go and read how much letters you need to generate enough entropy for your current cipher. And lastly you can substring the user's input in case he really overdid it.

And the funny thing is now you can 5minute google library for your language which makes all the math for you. But that would take too much effort. So yeah, plain text master race.

Isn't it the opposite? If it's encrypted the string gets way longer and the more characters you add the longer the encrypted pass

>encrypted password

Passwords should be hashed, not encrypted.

>Passwords should be hashed, not encrypted.

Why?

That's obviously what I meant

What really makes me rage is when a site accepts your password and then silently truncates it, but doesn't do the same on attempted login. """"webdevs"""" alright.

You run into this problem way more often than you should when using password managers.

Battle.net has the same Limit.

How can they have accurate size predictions of account data if passwords can have unlimited lengths?

Because hashed means non recoverable.

Hashes are fixed-length you dingus

>Why?
1. Attacker knows the password length (or password length + up to several characters in case of block ciphers), which means bruteforcing it is much easier.
2. There's a possibility of the attacker stealing also the master key, meaning they get all the passwords for free

Encryption is reversible. Hashes are not.

>are you storing your passwords in plain text?
>it's a 99,9% chance of it being store in plain text.
>So yeah, plain text master race.

on the contrary, if there's a lower upper limit for passwords it's because they're likely doing something dumb but it's also very likely that a DOS attack is a valid concern, it's all fun and games saying sites should support large passwords and use bcrypt until you realise someone with a few boxes free can take down your authentication server with a few dozen large password checks every second - cpu cycles aren't free and bcrypt is designed to be slow

ea/battlefield did that at some point, the website allowed you to register with passwords up to 16 length but the client only accepted passwords up to 15 length

>2. There's a possibility of the attacker stealing also the master key, meaning they get all the passwords for free

which is both a huge security concern for the website (you don't want people logging in as everybody if the master key is leaked) and for the users (suddenly no need to brute force thousands of passwords)

if you think encrypting passwords is a good idea you should probably pay a professional to implement any security features you plan on having

security.stackexchange.com/questions/17949/why-are-passwords-limited-to-16-characters

They're either STILL using md5, retarded, or using x-16 chars as salt.

I'm not even mentioning the times a ability or champion may not come out because of "code reasons"
now that's real bullshit.

Then how does the server authenticate the password per logon?

I don't understand that.

It hashes the password they're attempting to log in with, and compares it with the hash that's in the database.

you being serious? you enter password, if md5(entered password) == stored md5 password: success

Lol client is total cancer,it was developed by mongoloids with software that is trash (still using adobe on some parts of client)... Im not shocked that everythih else is complete shit too...

Tldr : kys op

It should be noted that md5 is bad for password hashing because it's fast, and a salt should be used, but yes, this post gets the basic point across

the same input will result in the same hash
therefore, except in the unlikely case of a hash collision, if the user enters a password whose hash matches the stored hash, then it's the correct password

>on the contrary, if there's a lower upper limit for passwords it's because they're likely doing something dumb but it's also very likely that a DOS attack is a valid concern
How about doing a hash client-side, sending the hash to the server (so you get the constant size), adding salt and then hashing it again?

You get:
- arbitrary password size (first hash done client-side so the server code is much easier to write)
- per-user salting (salt isn't sent to the client so it cannot be used to verify the existance of an account)
- stealing the database doesn't allow the attacker to login as it contains a salted hash of whatever the client sent.
- added bonus for the truly paranoid: your password (what you type) isn't sent over the secure, encrypted connection (if anything login-related is sent over unsecured connection we're dealing with larger problems here) and thus it's not available to the server at any time.

AFAIK Dropbox uses something similar now:
blogs.dropbox.com/tech/2016/09/how-dropbox-securely-stores-your-passwords/

So you can't reverse it

Jesus fucking christ Cred Forums is dumb

>DOS attack is a valid concern

So you exchange one of the many steps you have to take to be "secure" with a slightly increase of performance.

Also DOS should be taken into consideration somewhere else than your code. Like hosting, server, backups, bandwidth, topology of your servers, distributing your service across IPs, servers etc.

Also you can compute CPU heavy things on client side. Since JS exists and LoL's players already have huge bin blobs on their disk anyway.

...

t. riot webdev

>Not encrypting the hash

That's so fucking pointless, all that's necessary is a salted hash (actually ideally you'd be using a KDF which is many hashes).

Encrypting your database puts you ahead of many security people out there. Yeah it's a vector for DOS (easily mitigated with proper server and resource allocation) but the dude will have to crack the encryption and the salted hash which will hamper their efforts significantly.

That and with proper key rotation, you're golden.

That's the most retarded post I've read today

When will the LoL's database be hacked? I want to see the rage all over these faggots.

Are you implying an encrypted DB is less secure than an unencrypted DB?

You should hack it yourself. :^)

Kek

Still wrong. no matter how long your input is. the hash will always have the same amount of characters.

Why would you? The database needs to be in decrypted form in memory. If an attacker has access to a running server, they would also have access to the decrypted database.
That and performance issues will become a major concern.
That's why no one does it.