Live data from Hacker News

Hacker, Hack Thyself

blog.codinghorror.com

31–40 of 114 posts

Re: Hacker, Hack Thyself

#31
post #7

I saw a very interesting talk last year from someone who, as part of a company's security team, had set up a system that continually attacked the hashes of every employee's Active Directory passwords. If one was cracked, the employee would receive an automated email with a note containing the last few characters of their password and a suggestion to change it. I recall they also spoke on some security aspects of the…

That's a cool idea, but wouldn't it be more efficient to use something like zxcvbn to estimate the strength of new passwords and reject weak ones? That way you're not wasting electricity running a GPU array at full tilt 24/7.

Re: Hacker, Hack Thyself

#32
post #31
post #7

I saw a very interesting talk last year from someone who, as part of a company's security team, had set up a system that continually attacked the hashes of every employee's Active Directory passwords. If one was cracked, the employee would receive an automated email with a note containing the last few characters of their password and a suggestion to change it. I recall they also spoke on some security aspects of the…

That's a cool idea, but wouldn't it be more efficient to use something like zxcvbn to estimate the strength of new passwords and reject weak ones? That way you're not wasting electricity running a GPU array at full tilt 24/7.

It might not catch the kinds of things that seem strong but end up on word lists. `correctbatteryhorsestaple`, and even more so `correctbatteryhorsestaple1` or `correctbatteryhorsestaple!` would probably pass a "strength" test with flying colors, but you bet it would get cracked in a moment by any script kiddie with a word list.

Re: Hacker, Hack Thyself

#33
post #16

What this shows is that even with best practices passwords are a fairly weak security control. We need a standardised second factor id. The FCC or corresponding body elsewhere should mandate that phone networks and phones support a secure messenging protocol which could guarantee that a message could be sent to a phone number and only be received by that device. Password-only authentication is like locks on luggage,…

> We need a standardised second factor id

We've already got TOTP (RFC6238) and U2F. At this point it's just a matter of adoption.

Re: Hacker, Hack Thyself

#34
post #7

I saw a very interesting talk last year from someone who, as part of a company's security team, had set up a system that continually attacked the hashes of every employee's Active Directory passwords. If one was cracked, the employee would receive an automated email with a note containing the last few characters of their password and a suggestion to change it. I recall they also spoke on some security aspects of the…

Story time...please excuse the tangent, related to the above comment.

In the mid 1990s, I was the computer security officer for the 81st Medical Group in the USAF, which is the proper name for a rather large DOD hospital in southern Mississippi.

Though it was 22 years ago, the hospital was almost completely paperless. Every member of the staff, from doctors to orderlies, used one of the 10,000 or so VT320 terminals spread across a dozen or so building in the campus and beyond. Needless to say, on an average day, a person would enter their userid and password many times. Many of those accounts were very powerful, because we were networked with the rest of the DOD's medical records. One example report I ran with a doctor's account credentials was 'List everyone in the DOD, past or present, who is or was HIV positive.' ('Was' because the person could be dead.)

Furthermore, this entire system was reachable via the Internet, via AFIN (Air Force Information Network).

This probably strikes anyone reading this as...kind of nuts. And by today's standards it certainly in. But 22 years ago, most people weren't thinking in those terms.

The implications did freak me out a bit, once I took the job, and though I didn't have the power to do much about it structurally, I could do some things to improve password security.

So I had a dedicated (dating myself here) Pentium Pro Linux server that did nothing but run password attacks on our entire authentication database. On top of that was some automation I wrote that, once an account's password was guessed, would send automated e-mails, daily, to the account holder and their manager.

If the password wasn't fixed in a week, then their account would be automatically expired, forcing them to pick a new password.

The system didn't stop them from picking the same one as before, which people frequently did, but the automation was smart enough to expire their password again the next day without the grace period if that was done, which was annoying enough to get people to stop that practice.

This was rather...unpopular...among the staff. But I had that little 'HIV Positive Report' presentation I mentioned before. I said the account I ran that report from was behind the password '1234', and that anyone in the world could have logged in, run the report, and published the results. The thought of that spooked even the most technically and security clueless medical types.

Scare tactics? Yup. But sometimes scare tactics are justified.

Re: Hacker, Hack Thyself

#35
post #32
post #31

Earlier quoted context omitted.

That's a cool idea, but wouldn't it be more efficient to use something like zxcvbn to estimate the strength of new passwords and reject weak ones? That way you're not wasting electricity running a GPU array at full tilt 24/7.

It might not catch the kinds of things that seem strong but end up on word lists. `correctbatteryhorsestaple`, and even more so `correctbatteryhorsestaple1` or `correctbatteryhorsestaple!` would probably pass a "strength" test with flying colors, but you bet it would get cracked in a moment by any script kiddie with a word list.

zxcvbn accounts for the use of word lists. (And keyboard patterns, and common dates, and repeated characters, and a dozen or so other common patterns you probably haven't thought of yet.) Try it yourself: https://dl.dropboxusercontent.com/u/209/zxcvbn/test/index.ht...

And in fact, four random words is actually quite strong. The XKCD comic that password is taken from accounts for the use of word lists in its entropy calculation. In fact, it even _assumes_ the attacker knows the exact 2048-word dictionary you're selecting the words from. Even under those assumptions, four random words is _still_ a pretty strong password.

Re: Hacker, Hack Thyself

#36
post #3

Earlier quoted context omitted.

Wouldn't it be easer to just test the submitted password against the 10,000 most common passwords directly, and refuse it then?

Which they already do; from the post: > Users cannot use any password matching a blacklist of the 10,000 most commonly used passwords.

My question is, is 10k good enough? Wouldn't it be better to check against more? 50k?

Re: Hacker, Hack Thyself

#37
post #21

Earlier quoted context omitted.

I used to work at a University in the UK. One of my responsibilities was the email system. We constantly suffered targeted phishing attacks where the sender pretended to be from the IT department and required the recipient to respond with their password, for various made up reasons. Our spam filters captured most of these on the way in, but some still got through. And people replied. People replied all the time. Stud…

Interesting! Did you consider regularly sending phishing emails yourself, and automatically call out anyone who reply anything at all to them? I mean, you won't catch quite as many people, but eventually most will learn, one would think.

I do remember that idea being discussed. I can't remember why we didn't go ahead with it at the time.

Re: Hacker, Hack Thyself

#38

Earlier quoted context omitted.

I used to work at a University in the UK. One of my responsibilities was the email system. We constantly suffered targeted phishing attacks where the sender pretended to be from the IT department and required the recipient to respond with their password, for various made up reasons. Our spam filters captured most of these on the way in, but some still got through. And people replied. People replied all the time. Stud…

Nice to see that your second solution doesn't require passwords to conform to a format to work.

Yes. Second solution is much better if you can do it: faster, more efficient, more accurate, but it depends on using an authentication mechanism which gives the server access to the plain password during authentication, so it will not work in all situations.

Re: Hacker, Hack Thyself

#39
post #35
post #32

Earlier quoted context omitted.

It might not catch the kinds of things that seem strong but end up on word lists. `correctbatteryhorsestaple`, and even more so `correctbatteryhorsestaple1` or `correctbatteryhorsestaple!` would probably pass a "strength" test with flying colors, but you bet it would get cracked in a moment by any script kiddie with a word list.

zxcvbn accounts for the use of word lists. (And keyboard patterns, and common dates, and repeated characters, and a dozen or so other common patterns you probably haven't thought of yet.) Try it yourself: https://dl.dropboxusercontent.com/u/209/zxcvbn/test/index.ht... And in fact, four random words is actually quite strong. The XKCD comic that password is taken from accounts for the use of word lists in its entropy c…

By `correctbatteryhorsestaple` I meant exactly that. Four words are great. THOSE four words would be terrible.

Re: Hacker, Hack Thyself

#40
post #30
post #7

I saw a very interesting talk last year from someone who, as part of a company's security team, had set up a system that continually attacked the hashes of every employee's Active Directory passwords. If one was cracked, the employee would receive an automated email with a note containing the last few characters of their password and a suggestion to change it. I recall they also spoke on some security aspects of the…

> who, as part of a company's security team, had set up a system that continually attacked the hashes of every employee's Active Directory passwords. On the other hand of you are not part of the security team something like this can get you in some real trouble. Don't do it at home kids!

It can also get you hired, as long as you are dealing with A students.
Post reply on HN