Live data from Hacker News

Ken Thompson's Unix Password

leahneukirchen.org

391–400 of 665 posts

Re: Ken Thompson's Unix Password

#391
post #333
post #15

Ken Thompson: > congrats. https://inbox.vuxu.org/tuhs/CAG=a+rj8VcXjS-ftaj8P2_duLFSUpmN...

Offtopic. Many teams use mailing lists. That UX always scared me. Is anybody know good tutorials on how to getting started to use this kind of interfaces?

This is a common refrain, mailing lists do need a lot of instructions at the bottom to make sense — email wasn't made for groups. It's like 'group' SMS, your phone might provide you with a single chat window with all your friends, but what it really is doing is just sending a separate SMS to every one of the recipients.

So you need the 'the manual' attached to every message to make sure people get it right. Looks downright scary sometimes though, especially the prospect of getting swiped at by UNIX greybeards if you do it wrong.

Incidentally, I'm working on a modern version of this whole page in a Reddit-like interface. (https://aether.app) It doesn't solve all of the pains of listserv, but it does help with most, including this one you mentioned.

Re: Ken Thompson's Unix Password

#393

I'm shocked at how well the old hashing stood up; sure, it's totally crackable today, but a well-picked password still took 4+ days to crack on modern hardware, which is remarkable. (Granted, it doesn't sound like they did anything fancy like throwing a hundred cloud instances at it or something; I'm not saying you should use DES today:) )

> I'm shocked at how well the old hashing stood up; sure, it's totally crackable today, but a well-picked password still took 4+ days to crack on modern hardware, which is remarkable 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 hash or a KDF on password is making low-entropy passphrase harder…

Really it's because of a mixture of the two. The traditional DES-based crypt is basically a really early KDF - it was intentionally designed to be slow in order to thwart brute-forcing attacks. (Of course, since it was based on the speed of late-70s computers and had a limited password length, it's pretty feasable to brute force with modern hardware.)

MD5 wouldn't be invented for another decade or two...

Re: Ken Thompson's Unix Password

#394

Earlier quoted context omitted.

I'm conflicted about this. I know I'd be pretty upset if an employer starting talking to me about a plaintext password that's supposed to be hashed. The problem is that they brute forced it and then sent it directly off to HR? Yes, as a sysadmin it's perfectly acceptable to be searching for weak passwords, but reading the plaintext yourself for fun then scurrying to HR is kinda a slimy thing to do. As an admin you ha…

Former sysadmin here. I think there's a careful balance that needs to be struck, both by admins and users. As a user, you should realize that when you're on company equipment, privacy is more of a courtesy than a right. It's their equipment you're using. It's reasonable to expect them to use it in a way that furthers the company's interests. So act accordingly. As an admin, you don't ever go digging through stuff for…

> It's their equipment you're using.

I don't find this a very good argument. Sourcing inspiration from a sibling comment, it's also the employer's bathroom stall. I might be convinced it's okay to snoop when it comes to their network usage, but this is not the argument to do so.

Re: Ken Thompson's Unix Password

#395
post #4

Earlier quoted context omitted.

I would have borrowed "/.,/.," a long time ago had I heard about it sooner. That is just way too convenient.

My first password ever was qazwsx and I used it until I learned that it's included in "known" password text files and thus instantly crackable. However, I wonder how safe it is to take an "easy" password like /.,/.,/., and then add a bunch of exclamation points to the end, so that it's both long and not part of a dictionary. I'm sure password crackers are advanced enough to first try taking common passwords and then…

This article from 2013 shows some impressive password-generating techniques that cracked secure-looking passwords like momof3g8kids. It doesn't specifically give an example like MyDogRules###########!, but it seems reasonable they could get it by similar methods of concatenating multiple password fragments.

[0]https://arstechnica.com/information-technology/2013/05/how-c... (OK, the passwords were hashed only with MD5)

Re: Ken Thompson's Unix Password

#396
post #196

Earlier quoted context omitted.

I think it's very interesting how, despite knowing nearly nothing about the situation, everyone here is quick to doubt the victim, and make up scenarios (for which there is zero evidence) where the harasser is the victim.

There are no facts in this case available to us, the internet commenters; only 100% framing. In a different framing, the victim is the one who was unfairly fired, perhaps due to fitting in poorly or even malicious claims of misconduct by the harasser. And in this framing you are not only blaming the victim, but also attacking everyone who doesn't. See how this works? "Believe the victim" is circular reasoning, all it…

There are several facts alleged in this case that were provided by the user jedberg.

1: "One guy actually got fired for his password." This is a statement of fact, which we can initially accept as true.

2. He was already being super creepy and making the girl who sat across from him uncomfortable This is a statement of opinion with the appearance of a fact. The phrase "super creepy" is quite vague, to the point of being meaningless without further specification. Also, how jedberg can know that she was feeling uncomfortable should be in question.

3. "but she never told anyone." This unsubstantiates claim #2. If she never told anyone, then there was no way to determine the truth of the claim that he was "making the girl across from him uncomfortable." Note that even this statement may be false, as she could have told many people already without informing jedberg, and if so, would help to substantiate the previous claim.

4. Then we cracked his password, which was a very naughty phrase about the girl who sat across from him. Note that "we cracked his password" is a statement of fact, mixed with opinion that the phrase was "very naughty". Whether the password was "naughty" or not, I don't think anyone is disputing that the password was cracked.

5. I reported it to HR This is a factual claim.

6. who asked the girl This is a factual claim, and most probably true, with the exception that it could be hearsay if jedberg wasn't in the room at the time when it happened, which has not been specified.

7. who then said he was creepy This is a statement of fact. Assuming that jedberg heard this directly from her, we can call this statement true. The important bit, however, is the word "then". She only said that he was creepy _after_ approached by HR. If HR's question was "Don't you think that guy across from you is creepy?", then that would be considered leading and deceptive. If HR's question was "what do you think about the guy across from you", then that question would be leading. If HR's question was "what do you think about your fellow employees", then that question would be neutral and acceptable. Since the manner in which the question was asked was not specified, there is no way to know how this question affected her response. It is not reasonable to assume the question was leading or not leading without further confirmations, and this unfortunately makes the claim moot.

8. so they acted swiftly on the reports and got him out of there. This statement appears to be a reiteration of claim #1, I don't see anything additional here that affects the previous claim.

Later, jedberg said this:

9. he got fired for sexual harassment. This is a statement of fact; however, this appear to directly contradict the first statement that jedberg made, which was that he "got fired for his password." So, if we can accept that he got fired for sexual harassment, then he didn't get fired for his password, and the original claim is untrue.

In summary, 1) a guy got fired for sexual harassment. 2) The accused also had a password that may have mentioned something "naughty". 3) That password was noticed by an IT group and may or may not have had some impact on the termination. 4) The interviewing of the alleged victim may or may not have influenced her testimony.

Those are the specific facts that we're dealing with in this case. Dismissing this with the idea that "there are no facts in this case" is incorrect. The fairness or unfairness of the case is framed around these facts, with opinions given on both sides throughout this thread.

Re: Ken Thompson's Unix Password

#397
post #312

Earlier quoted context omitted.

Yep, you need both the input and hash to be strong. 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 used ambiguous language, "strong hash". 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…

Can ROT-13 really be called a hash though? It's literally an ancient chipher.

Re: Ken Thompson's Unix Password

#398
post #375

I had a password for an old school system (which I wrote) that was "any 21 characters where the 21st character is a 'z'". People would watch me type it (mashing 20 keys then the 'z') and be amazed I could remember a password that long.

You can "impress" people this way still, just by surreptitiously typing Ctrl-u to clear what you've typed so far.

I'm guilty of that. I tend to mistype my passwords a lot, since I try to keep them pretty complicated, but since I usually realize quickly enough to imperceptibly hit Ctrl-U and retype in a smooth motion, I just let onlookers believe that my password is very, very long.

Re: Ken Thompson's Unix Password

#399
post #312

Earlier quoted context omitted.

Yep, you need both the input and hash to be strong. 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 used ambiguous language, "strong hash". 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…

You could argue that ROT13 accidentally has second-preimage resistance because given m, you won't be able to find n≠m where ROT13(n)=ROT13(m). :-)

Re: Ken Thompson's Unix Password

#400
I remember cracking the password from a Windows system in high school. There was a centralized login mechanism using Novell but everything was cached locally. So you could boot a Linux CD and copy the password file to a memory stick, and crack at home. I think I used lophtcrack? The head admin account for the entire school district (basically root) had the password “north”. It took like a fraction of a second to crack. It was so simple that for weeks I didn’t even believe it to be true, and didn’t realize the name of the account was an admin.

I was expelled a few months later for all the fun I had after discovering this. Good times.

Post reply on HN