
Hacker, Hack Thyself - darwhy
https://blog.codinghorror.com/hacker-hack-thyself/
======
g_sch
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 system's design, like
how the cracked passwords never touched disk and had to be destroyed as soon
as possible, etc.

I wish I could find a recording or a writeup on this somewhere, as I thought
it was a pretty cool (and effective) approach.

~~~
mike-cardwell
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. Students _and_ staff. Even after being
constantly informed about the problem and told to not reply to such emails.
When they replied, the attacker would log in and start sending out spam.

Anyway, the format of our passwords was quite strict. I don't remember the
exact rules, but it required "special" characters and lower/upper case letters
and numbers and a minimum length etc. So what I did was write a system to scan
all outgoing email. It would search that email for all strings which matched
our password pattern. It would then attempt to authenticate against the Active
Directory with each of those strings. If any succeeded, it would block the
email, and the person sending the email would get a response telling them to
not send their password via email. I would also be Cc'd in, so I could keep an
eye on it.

This stopped several people a week from emailing out their login details to a
phisher. I wrote about it here:
[https://www.grepular.com/Mitigating_Spear_Phishing](https://www.grepular.com/Mitigating_Spear_Phishing)
\- With links to the source code. I also later came up with a simpler solution
and wrote about it here:
[https://www.grepular.com/Defending_Against_Spear_Phishing_wi...](https://www.grepular.com/Defending_Against_Spear_Phishing_with_Exim)

~~~
ggggtez
What if I send an email with a partial dictionary, hidden in an invisible HTML
block. If the user is blocked from replying, I know their password was in my
original email.

~~~
mod
How do you know they're blocked from replying?

------
mwcampbell
I wonder if Jeff and his team know about Dropbox's password strength
estimator:
[https://github.com/dropbox/zxcvbn](https://github.com/dropbox/zxcvbn)

~~~
nexxer
They do, it's referenced at [https://blog.codinghorror.com/your-password-is-
too-damn-shor...](https://blog.codinghorror.com/your-password-is-too-damn-
short/) which linked in this post.

------
sriku
I don't trust myself enough to manage passwords properly for some small
services I run 'cos I simply don't have the spare time to invest compared to
investing in functionality.

For that reason I've been trying out a password-less login for a while now
(works via email) and so far non tech folks haven't complained too.

It is pretty much as though you always used the "forgot password" mechanism to
login.

Wrote about it here - [http://sriku.org/blog/2017/04/29/forget-
password/](http://sriku.org/blog/2017/04/29/forget-password/)

~~~
psi-squared
That's a really neat solution, and avoids the cognitive overhead of having to
remember yet another password (or the security risk of re-using passwords). I
particularly like the way you tie the log-in token to a particular browser
session so that it can't be hijacked!

Plus by merging all of the log-in paths (registration, 'forgot password', and
normal login), you have _one_ thing to design and secure rather than _three_.
That seems like a huge advantage from a security perspective.

------
whoami_nr
I am not an expert on password hashing but I was wondering why can't the
websites hash their passwords twice using two different hash algorithms. That
way when the hashes are exposed, the attackers have to go through two
algorithms. Is the time complexity increase only marginal that people don't do
this ?

~~~
dsp1234
[https://link.springer.com/chapter/10.1007%2F978-3-540-28628-...](https://link.springer.com/chapter/10.1007%2F978-3-540-28628-8_19)

[https://link.springer.com/content/pdf/10.1007%2F978-3-540-28...](https://link.springer.com/content/pdf/10.1007%2F978-3-540-28628-8_19.pdf)

Abstract:

"In this paper, we study the existence of multicollisions in iterated hash
functions. We show that finding multicollisions, i.e. r-tuples of messages
that all hash to the same value, is not much harder than finding ordinary
collisions, i.e. pairs of messages, even for extremely large values of r. More
precisely, the ratio of the complexities of the attacks is approximately equal
to the logarithm of r. Then, using large multicollisions as a tool, we solve a
long standing open problem and prove that concatenating the results of several
iterated hash functions in order to build a larger one does not yield a secure
construction. We also discuss the potential impact of our attack on several
published schemes. Quite surprisingly, for subtle reasons, the schemes we
study happen to be immune to our attack."

~~~
emn13
In that paper they're concatenating two hash _outputs_ which obviously
(right?) only makes it _easier_ to reverse the hash - the attacker need only
pick whichever hash he can work with quicker, and find the preimage for that.
Given the fact that password entropy is much lower than hash entropy, the
preimage thus found is almost certainly the original password, not a collision
- rendering solving the other hash preimage moot.

If you want to force the attack to go through two hashes, you'd use
_functions_ sequentially (e.g. F(G(input)), not F(input)+G(input)), which the
paper at least initially doesn't talk about. I didn't read the whole thing,
mind you...

Note that password-stretchers like bcrypt/PBkdf2 use only fairly small
extensions to this idea, so clearly in general the construction isn't known to
be flawed.

------
tbabb
IANA security researcher, but isn't it a bad idea to publicly post a list of
known-good passwords associated with accounts on your own site?

I raised an eyebrow at the hash/salt table alone.

~~~
bfstein
My guess is they forced password resets on those users whose passwords were
compromised.

------
orng
Is my math failing me or wouldn't 8 digits result in 10^8 possibilities rather
than 8^10?

~~~
eriknstr
You are correct that there are 10^8 possibilities for a string of 8 digits.

10 possibilities in position 1

10 possibilities in position 2

...

10 possibilities in position 8

10 * 10 * 10 * 10 * 10 * 10 * 10 * 10

Alternatively one can even simply observe that 99999999 is the highest number
possible and since 00000000 is possible also then we have 99999999 + 1
different possibilities = 100000000 = 10^8

------
dukedougal
I built my latest application using Amazon Cognito for user management. My
application and database don't ever know anything about the passwords.
Amazon's problem.

~~~
pibefision
Considering OneLogin's current events I'm not sure if this approach is more
secure or a good solution. ([https://techcrunch.com/2017/06/01/onelogin-
admits-recent-bre...](https://techcrunch.com/2017/06/01/onelogin-admits-
recent-breach-is-pretty-dang-serious/))

~~~
rekshaw
You have two choices: try and do it on your own, or delegate to someone who
you think can do it better. There are risks either way. Considering how much
data Amazon has, they probably invest significantly more than you (or
OneLogin) on security.

------
peterwwillis
I'm comfortable using passwords <20 characters distributed among a range of
sites because I have a realistic view: if one gets compromised, not every
account does, and most accounts are not critical. Some are luggage keys, some
are Medeco.

But those are bad comparisons. A key and lock is an asynchronous single use
authentication+authorization mechanism. Passwords are just the authentication
part, so trying to replace these just requires we have a secure way to
authenticate ourselves.

We have the benefit that we are using digital systems, so our authentication
can be digital, too. We can also rely on multiple factors to improve how
authentic this process is. Biometrics, digital files, access to other accounts
and networks, offline code generators, and personal information all provide
lots of authentication data and multiply the effort needed to defeat the
system. By combining all these factors, we can create a new digital key that
is far more difficult to defeat than old methods by themselves, and ultimately
is more flexible because it can be made up of any of these things.

The problem mainly seems to be that we live in a world of different locks, and
most locks don't accept this particular kind of digital key. We've hacked
around this problem and made some attempts at more compatible solutions, but
they really fall short of their true potential.

In the future, you should simply be able to use any system and know that it
will authenticate you in a way that can't be copied or cracked. Today that
just isn't the case. So for now, maybe we should move the goal posts. We can
keep making our keys more unwieldy, but we can also get more guard dogs.

The guard dogs need to exist not only to protect the locks, but the keys, too.
If you go to unlock a door, a thief can knock you out and steal your key. Each
aspect of our digital access needs guard dogs. We can no longer accept
insecure communication methods, nor insecure computing platforms, to exchange
our authentication. I think the real challenge going forward is rethinking how
we process data altogether.

~~~
dublinben
It's a lot easier than all of that. New two-factor authentication standards
like U2F achieves most of that with just a simple, inexpensive hardware token.

~~~
Bakary
U2F is cumbersome when you have to travel and change phone numbers frequently.
In many cases there is no real way to have a line to one of your
authentication methods, since you can never get the SMS confirmation.

~~~
peterwwillis
U2F does not require SMS, and that's what it's designed to work around:
problems inherent to "traditional" 2nd factor authentication. It does this by
a secure connection from your browser (which does a challenge/response with
your U2F token) to the server. You can connect your U2F token to your phone
and auth on any network without SMS.

But U2F is really only a stopgap technology designed to provide a better
mechanism than SMS or TOTP. There are still difficulties users will find with
this mechanism that are problematic to secure or make less cumbersome, slowing
adoption and security in general. And U2F still has several attacks that will
work against it, making it somewhat trivial for malware to take over an
account.

I envision a future where not only are there many factors we can use to
authenticate, but that we might never need to "reset" our accounts again. That
the majority of attacks on the user could end, and that servers will be more
resilient to both general attacks and specifically data exfiltration. And that
the data we use to secure accounts on the server can't be reused. An almost
secure technological world.

This requires implementing strong security measures in all of the computers we
use today. It also requires the adoption of universal multi-factor
authentication methods, and a methodology to protect them from abuse by
attackers. You can't get there by tacking more complicated mechanisms onto
computers that are already not secure.

~~~
Bakary
My bad, I actually confused the U2F acronym with 2FA. You are correct, of
course.

------
Qub3d
Suuuper nitpicky, but in the paragraph directly below Dark Helmet, Jeff calls
his Graphics Card a 1080 GTX Ti. The GTX goes in front of 1080, since GTX is
the general product line.

~~~
neogodless
You are correct. It is a mistake. It's also confusing naming, because not too
long ago, nVidia named their cards with GT and GTX as a suffix, such as the
GeForce 8800/9800 GT and GTX.

~~~
wlesieutre
Once they run out of numbers again maybe they'll turn it into an infix?
Looking forward to the Nvidia 48GTX70!

~~~
KeyboardFire
pshh, that's nothing compared to the circumfixed Nvidia GT5790X

------
dzdt
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, even with best
practices.

~~~
raesene9
I'm not sure why you think this article shows that with best practice
passwords, it's a relatively weak control?

From the article a user choosing a random (i.e. not in wordlists) 8 character
password with upper/lower/numeric characters could expect an attacker to take
3 years to crack the password (and that's attacking one hash!)

Now to be clear, I totally think that passwords are a bad idea (mainly because
humans aren't well equipped to choose and manage large numbers of random
strings) but I don't really see why this article advances that concept?

~~~
dzdt
Quoth the article:

 _A very motivated attacker, or one with a sophisticated set of wordlists and
masks, could eventually recover 39 × 16 = 624 passwords, or about five percent
of the total users. That 's reasonable, but higher than I would like._

~~~
raesene9
Sure so the attacker has entirely compromised the site in the first place,
offline brute-force only works where the attacker has already got a copy of
the database.

They've then eventually got access to 5% of the user's passwords, and the
one's they got access to were all based on dictionary words...

Assuming that the site has any level of reactive/detective controls, they've
noticed the breach and invalidated the passwords, thus rendering them useless.

What I'm saying is the offline password cracking times demonstrated in this
article don't seem to indicate any more weakness in the use of passwords than
was already known. the percentage of attackers who are going to bother with
hitting a PBKDF2'ed password database on a forum site with any level of
dedicated cracking past a run with some dictionaries, just isn't that high.

Attackers are drowning in existing compromised password databases already
many/most of which exposed clear-text or weakly hashed (MD5/SHA-1 with no
salt) passwords, so realistically speaking the incentives for getting another
set where you really have to work hard to get them, isn't likely to be that
high unless it's a high value site.

If you want examples just look at the lists on
[https://haveibeenpwned.com/](https://haveibeenpwned.com/) 500 million
accounts with cleartext passwords from a single dump is at the top of the
list.

That said, I admire discourses efforts to move the bar higher by increasing
complexity and blocking weak passwords, all helps people move away from less
secure alterntives

~~~
codinghorror
well yes, that's true, you don't need to outrun the bear, you just need to
outrun the person in front of you ;)

Easy targets will always been compromised first.

~~~
raesene9
strong password hashing definitely has it's place as part of overall app.
security.

Where I think many/most applications would benefit from more security is in
detecting/reacting to attacks.

Most apps have no controls in this line at all, and make an attackers life
very easy in that they can keep trying vast numbers of attacks without being
blocked by the application.

There's been some decent foundational work done on this by things like OWASP
AppSensor
([https://www.owasp.org/index.php/OWASP_AppSensor_Project](https://www.owasp.org/index.php/OWASP_AppSensor_Project))
but I've not seen many applications actually implement the guidance...

------
tarr11
Has anyone ever done an analysis of what impact these kinds of breaches (like
OneLogin for example) have on either end users or the company?

Ie, we often describe breaches as "really bad" but it would be good to
quantify in terms of things like:

\- Revenue Lost (Company)

\- Reputation Lost (Company)

\- Time Lost (Company + User)

\- Increased Costs and Penalties (Company)

\- Assets lost (Company + User)

------
novaleaf
very surprised nobody here or the author mentions Argon2, which is like scrypt
except better, and is hardened against GPU attacks.

[https://en.wikipedia.org/wiki/Argon2](https://en.wikipedia.org/wiki/Argon2)

~~~
codinghorror
is Argon2 ready for prime time and tested?

~~~
novaleaf
yep, i use the npm package, it works great.

------
Sniffnoy
Most of those passwords that got cracked, my reaction is, OK, of course that's
a weak password... but "1qaz2wsx3e" and "A3eilm2s2y"? Geez! How'd they get
those?

~~~
chime
> 1qaz2wsx3e

That's just diagonals on the QWERTY keyboard.

> A3eilm2s2y

Apparently that's an in-game password for
[https://en.wikipedia.org/wiki/Parasite_Eve_II](https://en.wikipedia.org/wiki/Parasite_Eve_II)

Commonly used passwords can be pre-hashed and easily cracked.

~~~
Sniffnoy
Interesting, thanks!

------
git_SHA
Would it be a bad security practice to keep a database of the SHA hashes of
maybe the 10 000 most common passwords then alert users who try to use them?
Obviously you would do the comparison before applying your actual
bcrypt/PBKDF2 function with salt.

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

~~~
proaralyst
Which they already do; from the post:

> Users cannot use any password matching a blacklist of the 10,000 most
> commonly used passwords.

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

~~~
gwern
Presumably more is always better, but there's a very long tail of passwords so
the hit rate will drop off a cliff, and now you're storing 5x as much data for
increasingly questionable benefit.

------
peterclary
Encrypting the hashes in the database would make it safer. That way the
password hashes can't be attacked in this way unless they can decrypt them
first.

~~~
raesene9
Encrypting passwords wouldn't add a lot here unless you're using some
mechanism to protect the encryption/decryption key (like using a Hardware
Security Module), as an attacker who compromises the database is likely to
compromise the key at the same time.

If you do have a hardware security module, then why not just do away with
hashing altogether, encrypt the passwords with AES-128 and you'll likely be
fine (as long as the attacker can't extract the key from the HSM)

~~~
bcoates
It's slightly useful if you only give the key to your application servers, and
not your database servers. Now you need an application server breach and not
just read access to a database.

It's not unheard of for something like a decommissioned database backup to
wind up insecure and on the internet without being properly wiped, causing a
whole-db leak without anyone actually breaking into a production system.

Not sure it's worth the effort:reward though

------
eriknstr
Once they have the hash type table in place they should switch to Argon2.

