What the fucking shit, was changing a microsoft password and it literally caps you at 16 chars?!

So that the pw is micro and soft.

MD5?
CHAR(16)?

@Root wouldn't surprise me tbh

Seriously? Let me check real quick with my own account.. I know that it puts a hard limit at 100 chars, but if there's yet another one at the backend truncating everything after 16th char, that'd be horrible... Sakurity at its best.

Just checked in my own Outlook account (pretty much Microsoft account these days) and it doesn't let me in if I don't enter exactly the 100 chars that make up my password :/ where exactly are you experiencing this?

(as for why I'm comfortable with telling my password length for any bruteforce kiddies out there to crack, even though there's now no need to go through 1-99 anymore, good luck bruteforcing at 100 chars that change every couple of months :v)

@Brosyl I'm not acting out of good faith at all - I've experienced the exponential difficulty increase with each character added by bruteforcing some hashes myself. Even bruteforcing an MD5 hash at 11 characters becomes quite tedious.. 12 can take multiple days, 13 multiple weeks.. and at 100 chars it's impossible even with all the GPU's across the world combined. That is not to say that MD5 is secure or that 12 characters (and as GPU's improve eventually 16 chars) will suffice. What I'm saying is that bruteforcing is incredibly time-consuming and often a last resort. More often than not, dictionary attacks or social engineering will be far easier to pull off. In my case where my password is randomly generated however, dictionary attacks are impossible and I'm not very susceptible to social engineering in this regard either.

As for the method I'm using to generate the passwords - it's the entropy pool of whatever Linux host I happen to be using at the time. So it depends on how that entropy has been collected.. usually it's disk activity, RDTSC (in case of haveged), network activity, delays in reads and writes, gyroscope readouts, ... all usually in the extremely small digits so that they can't be influenced by human activity even if that's desired.

@kenogo Partially right, partially wrong.

On servers passwords are stored by first running whatever the user chooses as their password through a hash function (these days usually bcrypt) and then storing its output. Authentication is then done by running whatever the user enters as their password through the same hash function and comparing the result to what's in the database.

Hash functions are one-way functions - they can't be reversed. So password cracking is done by running that same hash function with input that's often dictionaries (aka wordlists) and deviations thereof (leetspeak etc). When the hash matches, you cracked it. But due to the nature of hash functions that's often done by educated guesses.

Needless to say, to start cracking a database you'll need the database first. So when someone can steal that from Microsoft's servers, that's when the cracking can start.. until then, all odds are off. Usually websites kick you out after 5 attempts or so.. and it's extremely inefficient to constantly have to load the website and submit form data to it too.

But let's say that the database is stolen, and cracking can start. That's when GPU's are employed, because hash functions are fairly simple math and can easily be parallelized. GPU's with their hundreds of cores are a perfect candidate for that. Hence why Hashcat is usually run on powerful GPU's that expose their cores for GPU programming (CUDA in particular). They make the cracking process as fast as multiple millions of hashes (megahashes) per second.

Some extra material: https://youtube.com/watch/...

@Condor I'm pretty much a noob on this topic I save hash and salt for every user. Because then as how I understand even if u crack one password the others are still save is this true or complete bullshit ?

@noogli The results of whatever value the hash function returns is compared against all the hashes in the database, so crackers aren't attacking one password at the time and then going to the next in a serial manner - instead all the hashes are attacked simultaneously in a parallel manner. The easiest ones (password, 12345678, qwertyuiop or whatever) come out first, then come the more difficult ones. Some won't ever be cracked at all but a large percentage usually will (because users are terrible at choosing passwords).

Salting is a good practice because it protects against rainbow tables. Depending on the hash function used (something like SHA512 or bcrypt should be good) your database should be secure as well. However if it's using MD5, SHA1 or the likes, change it ASAP!

If you're interested, you can extract the database out of the server and do an audit by running Hashcat against it.

@Brosyl @Condor portal.office.com, basically a microsoft account.

@Condor intrresting discussion btw

@JoshBent Same thing there it seems.. perhaps it's something in your particular environment? And thanks ^^ I always like to talk about security topics like this.

@Brosyl Exactly! Chances are always there that people will defeat the stats and get it right faster than the stats would predict. But the chances are so low that I'm not very worried about it. Especially since the password changes often.

Quantum computers and their alleged ability to parallelize stuff is similar to that of many cores of the GPU but exponentially more worrisome. I truly hope that common algorithms will hold up. The amount of data that common passwords now protect along with how shitty some databases are still configured still worries me to this day.