It didn’t take long because everyone had a password that was in the dictionary.
Needless to say, people were not happy with the messenger.
I'm actually not sure anymore what the details of their return email was, as it was over 25 years ago. But it was basically, "We will report you to law enforcement if you contact us again."
In hindsight some teacher must have spoken up for me to come up with the solution when they were trying to come up with an appropriate response.
I had to go apologise to IT (who could barely keep a straight face) at college for sending a message from 'God' saying "I saw what you did last night and it disgusted me".
I thought it was going to just the lab but since I was poking around in something I really didn't understand I manage to send it out site wide.
Fortunately they saw the funny side.
Around the same time, someone at my school made a much, much worse semi-accidental prank. Semi-accidental because he didn't think it would work. See, the campus list serve was setup to only allow certain senders to send messages. Makes sense, only a few top administrators should be able to do that. This person theorized that a simple <smtp: from> hack, using an authorized person's email, might circumvent the restriction. He was right! Unfortunately, rather than "test 1 2 3" or something, he sent a message, from the president, that all classes had been cancelled. Had he stopped there, maybe it would have been chalked up to a prank. But he went further: The president would be using this free time to, um, entertain amorous visitors at their leisure. So, yeah, expelled. His excuse, when interviewed by the student newspaper, was "I didn't think it would work."
I've been able to do it at every university I've studied or worked at.
"No one will ever guess this!"
Actually that was the first time that i heard the word Linux and learned the meaning just few years later.
It was actually decently well received by the department head; he sent out a memo to the staff to not use their wives names for emails and looked like an early computer security innovator in the physics department.
So I threw the OpenMP variant of John the Ripper at it (I'd just built a 8C/16T Ryzen machine and was curious) it broke ~80% of the passwords in under an hour and all of them over an afternoon of not been in use.
Went to see the boss and gave him the list of passwords including his (which was one of the weaker ones) - he gave me the time to fix it and some other glaring security issues.
The more things change the more they stay the same.
I know enough about security to know that I really don't know about security.
A coworker and I stumbled into this one morning when I was helping him figure out how to remotely invoke a linux command from a windows gui. I don't recall why we were using rsh as we'd normally ssh into our servers. As we sat there trying to figure out how to enter the password, we decided to just try and run the command w/o a password. We were shocked when it just worked - we were never prompted for a password. When I reported this to my director, he asked me how bad it was. I was like, watch this: I sent an email as the CEO to him saying "you're fired.". He immediately went to our infrastructure team to get it fixed. Fun times...
I'm not sure anyone ever gets past this point. There's way too much for any person to know and not enough hours in a day or days in a year or years in a lifetime to master everything. Even when it comes to computers in general at some level it just becomes magic to me. I might be able to point to a chip and say "that's the sound chip" or "that's a math co-processor", and even write software for it, but I have no idea what goes on inside and I wouldn't know where to even start trying to build one from scratch.
It's not because the hash is strong, but the password itself is strong (if the attackers don't know additional information about chess). The sole purpose of using a strong <del>hash or a</del> KDF on password is making low-entropy passphrase harder to crack by increasing the cost of every round, especially for cryptographic purposes. But if the passphrase is already strong (6 random words from the Diceware wordlist), you can use MD5, and I won't be surprised if it takes one year to crack. Having 10 random words is guaranteed to be uncrackable under all circumstances, because it's literally a 128-bit key.
If your password has 80-bit of entropy, it makes even listing all possible passwords (without any hashing or encryption) a difficult job. Symmetric encryption works in a similar way, it's secure not because of the computational resources it takes, but the number of possible keys it has.
What is the moral of the story? Consider to use a password manager!
Is this actually true? Note that you don't need the actual password, just a hash collision.
But if a hash, h(m), is given, finding m' where h(m) == h(m') is much more difficult, it's known as a second-preimage attack. "Image" basically means "output", "preimage" means "input", "second-preimage attack" means "find another input that has the same output already given here".
Wikipedia says a preimage attack against full MD5 still requires 2^123.4 steps (2009), only a theoretical possibility. Second-preimage should be much harder.
I don't know if there are improvements, but it's still extremely difficult. Well, of course it's not to say that you should use MD5.
A weak hash reveals information about its input, narrowing the search space. In the example case of md5 or rot13, you can use this to compute collisions for a given hash.
Also, a hash that is lightning-quick to compute is faster to brute force. That's why bcrypt has a tunable "cost" factor - to make the hashing take longer and make guessing the password slower.
I should've used "strong KDF" rather than "strong hash", a hash can be strong for other purposes, but makes a poor KDF for hashing passwords, such as single-round SHA-256.
In the ideal world, if your password is a random word with 128-bit entropy, no strong KDF is needed, there's no need for PBKDF2, bcrypt, or Argon2, a single round of SHA-256 is sufficient.
> In the example case of md5 or rot13
MD5 still has strong preimage/second-preimage resistance, unlike ROT-13.
But nobody uses random 128-bit strings as passwords, here's how key stretching and cost-factor comes to play.
* Where "plain" excludes a technical or mathematical definition that might include e.g. troll_hash(x) { return 9; }
Using chaining, encipherment of the last block is also a hash of the whole input.
Secure hashes are optimized for different characteristics than typical ciphers, but with enough headroom and time each can fill in for the other.
Of course some are not very good, for either use.
26 (a-z) + 26 (A-Z) + 10 (0-9) = 62 characters This which can be represented with (just under) 6 bits of information. (2^6 = 64). And 128/6 < 132/6 = 22.
I'd guess quite a few people who use password managers use password this length...
Rot13 is a function with a one to one mapping between the domain and codomain. If you have the output you can apply a function to get the input.
That's why you can have a hash function like h(x) = 0, whose value gives you no information about x, and still not being able to use it.
MD5 wouldn't be invented for another decade or two...
Which shows that it is fairly strongly "unique", since no-one else has used it and been pwned (or he hasn't reused it and been pwned).
You can download all the hash files if you wish to run purely locally.
Also the site hosting Troy's list is Cloudflare. Cloudflare act as a https proxy for a large number of sites, so they already have access to a large number of passwords.
Actually, I don't understand your comment.
It's great that sensitive breaches are apparently hidden but I'd be wary of judging for other people what is sensitive. Some like Ashley Madison are obvious, others less so.
It’s probably safe from the casual attacker who just downloads a password list and runs a one word dictionary attack, but for a dedicated attacker, let alone a nation state, it’s not secure.
TL;DR: Just use AES. Even an ASIC isn’t powerful enough for that. Searching the entire key space would take more energy than the universe has. Compare that to DES that can have its entire key space searched in a few days.[0]
Edit: you said triple DES, not single. My point still stands. DES, even 3DES, is not secure. If I can crack a DES password in 4 days, I can crack a 3DES password in 12. AES with a strong password is virtually uncrackable.
It's multiplicative, not additive. 3DES is about 2^56 times as difficult to crack as DES. (Not 2^112 times because there is an attack that effectively limits it to twice the effective bits of DES, rather than the three times you might expect at first).
* Meet-in-the-Middle attack.
https://en.wikipedia.org/wiki/Meet-in-the-middle_attack
This attack is surprisingly simple, if you encrypt the message twice by
ciphertext = encrypt(encrypt(message, key1), key2)
decrypt(ciphertext, key2) == encrypt(message, key1)
But in this case, the attacker can obtain all the 2^56 possible encryption of message by enumerating key1, put it in a lookup table (assume the table-lookup time is O(1)) , then we can try all possible decryption of ciphertext by enumerating key2. Then compare it with the lookup-table for a match, bingo!
If key is 56-bit, the attacker gets 2^56 outputs for the left side, 2^56 outputs for the right side, total number of operations is 2 x 2^56 == 2^57, not 2^112.
To increase the security claim to 2^112, we need triple encryption, not double encryption, thus 2DES is never used.
The idea that simple double-encryption doesn't work because of such a simple attack shocked a lot of newcomers.
If you’re using 3 different keys, yes, that makes sense. But if you’re just keystretching one key, wouldn’t it just take 3 times as long because you encrypt, decrypt, encrypt (3 processes)?
1. Would it be safe to build a password hash like crypt() based on 3DES today?
Maybe, kind of, it depends, don't do this. "Based on" is key here. You'd have to come up with some way to try to use 3DES in this fashion, just as the developers of Unix crypt() used DES. Basically you're trying to build a cryptographic hash out of a primitive that's not really intended for that purpose, you also need to add more salt than the Unix team did back then, and then you need it to run very slowly, preferably on everybody's hardware not just the generic (likely x86-64) general purpose CPU you're using. Lots of people already built _good_ ways to do password hashing in the 21st century, and if none of those are available somehow you should just use PBKDF2 with SHA256 and a nice big iteration count and that'll be tolerable.
2. Oh, I didn't realise, I just meant is 3DES fine for encryption?
You should not do this. The main thing wrong with DES is the key size is too small, which 3DES fixes (effective key size with full 3DES is 112 bits, which is very short today but probably not the biggest hole in whatever security system you're building). But the next biggest thing wrong with it is that it's a block cipher with a small block size, 64-bits. 64-bits is small enough that bad guys may be able to collide your blocks and set fire to everything. To avoid this: Don't use 64-bit block ciphers, go get a real cipher like AES that uses 128-bit blocks. Done. Why are you still here? Could it be secure if you can defuse the collision risk (e.g. you only encipher very small amounts of data)? Sure, but now you're defining the problem to make the choice of primitive look safe, which is always a terrible idea.