1.
Passwords
Kevin O'Brien
Washtenaw Linux Users Group

2.
The server side
● Your password is stored on a server
somewhere
● How securely?
● May depend on the nature of the site

3.
Access is the asset
● You have a password to grant you access to an
online resource
● You want to keep others from this resource
● But some resources are more important than
others

4.
The site owner controls this!
● The only choice you have is the password you
will use
● The site owner needs to secure and protect it
● Good luck if that site is Sony

5.
Threats aimed at you
● You are the biggest threat
● Social engineering is still an excellent way to
get your password
● “Hi, I'm Ted from IT, and I need to verify your
password...”
● Or it might be an e-mail with a clickable link to
malware

6.
But are you the best target?
● Social engineering is retail
● Hackers want to go wholesale
● You are only a good individual target if the
payout is compelling
● That means it is personal
● Or that you have something really valuable
(e.g. intellectual property, access to corporate
assets)

7.
Money makes the world go round
● The best financial payoff in most cases is by
cracking a business database of customer data
● Right now companies are largely escaping
liability when this happens
● This creates a type of moral hazard
● Companies will only spend money on security
when the cost of security is less than the cost of
failure

8.
Password Proliferation
● These days almost any site you go to demands
a login and password to do just about anything
● This creates problems because people cannot
handle this in a safe manner
● For instance, every password must contain a
letter, a number, a symbol, a squirrel sound,
and a Sanskrit hieroglyph

9.
Sites induce failure
● If you need a ton of passwords, chances are
you will use the same one over and over
● And if you use the same password to post a
comment on the Rabid Rabbit blog as you do
for your bank, a cracker can attack the blog to
get into your bank account.
● So step one is to triage your sites by
importance

10.
Important sites
● A site is important if it has an asset that you really
want to protect
● Banking
● Health information
● Email
● These sites should have unique and secure
passwords

11.
What can a cracker do?
● Well, if they can get into your bank account,
they can wire money from your account to an
account in say Belorussia
● And you may be liable for the money in that
case, not the bank
● Disable any online banking features you don't
absolutely need

12.
Throwaway sites
● If you need a password to comment on a blog
post, that is throwaway
● The password here should never be one you
use on an important site
● But it probably does little harm to use the same
one multiple times if you are accurate about
your triage

13.
How crackers work
● They may start with a targeted attack on an
individual with access (spear phishing) to get a
password
● Or they find a weakness in the online/network
software (e.g. privilege elevation)
● Either way, they get access to the database

14.
Worst case scenario
● The site has simply stored passwords as clear text
● This means the cracker has everything as soon as
they get the database
● One possible sign of this is when password length
is limited to a certain number of characters
● They may not tell you. Try leaving off the last
character and see if you get in

15.
Hashing
● Uses a one-way function to encrypt the password
● Easy to compute the hash
● Infeasible to reverse the process and get back the
original
● Infeasible to modify the original without modifying the
hash
● Infeasible to get two originals with the same hash

16.
Infeasible?
● We are talking about current technology
● We can mathematically analyze the level of
resources needed to crack a hash using current
technology
● We can reasonably forecast the advancement
of that technology absent fundamental
breakthroughs

17.
Arms race
● But it is an arms race
● NSA, GCHQ, and criminals (hard to tell the
difference sometimes) are all eager to break
encryption
● Researchers are busy researching
● Quantum computing could change the field
drastically

18.
Hashing algorithms
● MD5 – created by Ron Rivest (RSA) in 1991, but
no longer secure
● Secure Hashing Algorithm 1 (SHA1) – Created
by NSA and required in many government
applications, but found to be less secure in 2005,
leading to SHA2
● SHA3 was recently specified after a competition,
but is very new and not in wide use yet

19.
So what does a responsible owner do?
● Use encryption
● Definitely not MD5
● Hopefully not SHA1
● Ideally SHA2 or SHA3, but for now SHA2 is
your best bet.
● Note that SHA1 certificates are already
scheduled for EOL (Google, right now;
Microsoft, 2017)

20.
How passwords work in practice
● Generally, your password is transmitted to the site
in the clear, which makes you vulnerable to man-in-
the-middle attack
● That is why an SSL connection is important for any
site that is important
● Browsers are starting to be configured to do this by
default
● EFF has a plug-in for this as well:
https://www.eff.org/https-everywhere

21.
Hashing on site
● The password is then hashed by the Web site,
and the hash is stored
● On later logins, the password is again hashed,
and the hashes are compared
● Done properly, the hash cannot be cracked by
a frontal brute force attack with current
technology

22.
Dictionary attacks
● This is the way most attacks are done
● A large number of passwords are created and
hashed by the crackers.
● They can then lookup hashes in the database
against their dictionary
● Generally, at least 50% of the passwords in a
database can be found by this method fairly
quickly

23.
The bad news
● A lot of people use known poor passwords
● “password”, “1234”, “letmein”
● Leet-speak is no defense, the dictionaries all
have that included
● Many people use the same bad password, so
all of them will will fail at once

24.
Solution: Salted Hash
● A random number is added to the password
before it is hashed
● This is called the “salt”
● The dictionaries won't work unless they are
compiled using the exact same random number
● The salt has to be stored as well as the hash
for future login purposes

25.
Salt is discoverable, but no matter
● The salt is probably in the same database as
the hash
● So crackers will get the salt
● But then they need to compile their entire
dictionary for each salt to get a possible hit
● If every account has a different salt, that is a lot
of computation

26.
Salt explanation
A really good explanation of how to do salted
hashes correctly can be found at:
http://www.codeproject.com/Articles/704865/Salte
d-Password-Hashing-Doing-it-Right

27.
You have a responsibility too
● We looked at what site owners ought to be
doing
● But you too have a responsibility
● You need to create passwords that are less
likely to fall to a dictionary attack
● But remember this is an arms race, you need to
follow changes in technology and be ready to
make your changes in response

28.
Entropy
● Essentially, the degree of randomness in a
system
● @^$(hodjhij6 is pretty random
● “123456” is not at all random
● Nor is “password”
● Random = less likely to be in a dictionary

29.
Uncrackable?
● Possibly, if both you and the site do everything
correctly
● But changes in technology affect this
● The NSA is storing a whole bunch of encrypted
messages for the day they can crack them
● If this is your concern, you need to be very
vigilant and follow the technology

30.
Realistically...
● What most of us really need to do is not have
our bank account drained by a bad guy
● Or have our health information revealed
publicly
● Or have our identity stolen
● Etc.

31.
Don't reuse passwords
● This is the most common mistake people make
● Crackers now get passwords from one site and
start trying them on banks
● They get enough hits to make this very lucrative
● Any site that is important should have a unique,
strong password
● Probably OK to have a standard password that
is throwaway for low-value sites (e.g. blogs)

32.
Add to the entropy
● Avoid common names
● http://splashdata.com/press/worstpasswords2013.htm
● For some reason “monkey” is very popular
● The ironic one is “trustno1”
● But any word or name is bad

33.
Entropy in action
● Suppose you have a 6-character password
made of random lowercase letters
● You have 266 possible passwords (assuming
standard English alphabet)
● 266=308,915,776
● How good is this?

34.
Hashing mathematics
● Bitcoin mining works by calculating hashes
● Some very clever people have a monetary
incentive to improve hashing performance
● As of this writing I have seen reports of 800
billion hashes per second in bitcoin mining rigs
● So 308,915,776 combination can be checked in
a very small fraction of a second using
equipment available to the general public today

35.
Adding to the field
● If we have a mix of upper and lowercase, that
gives us 526=19,770,609,664
● Better, but it still only takes a bitcoin mining rig
less than a second
● Add in numbers, and 626~=57 billion
● Add in special characters, and 956~=700 billion

36.
Password Haystacks
● Term coined by Steve Gibson
● The way to make it harder to search for a needle in
a haystack is to make the haystack much bigger
● This approach says length trumps everything
● Gibson claims that “………..pass……………” is
actually secure as long as the cracker doesn't
have advance knowledge of your particular
algorithm

37.
Dictionaries and long passwords
● Suppose you create a password of 30
characters
● You use all 95 keyboard characters
● And your password isn't limited to only 30
characters
● This gets interesting
● In theory, the total number of combinations is
95+952+953+954+....9529+9530 = 2*1052

38.
How big is that?
● Assume a bitcoin mining rig can compute a trillion
hashes per second
● A trillion is 1012
● So the number of seconds needed to search this
particular haystack is 2*1047
● One year has 3*107 seconds
● So it requires 6*1039 years to search this
● The universe is 1.3*1010 years old

39.
Computationally infeasible
● This is the definition of computationally
infeasible
● But note that crackers are not sitting still either
● A long passphrase made up of dictionary words
is vulnerable
● http://arstechnica.com/security/2013/08/thereis
nofatebutwhatwemake-turbo-charged-cracking-comes-
to-long-passwords/

40.
Long and random
● The only way to guarantee (for now, remember)
that your password cannot be cracked is to
have passwords both long and random
● If quantum computing comes in, everything
changes
● But quantum computing will change encryption
technology as well, so the world probably will
not come to an end

41.
Implications
● Everyone needs long, random passwords
● Almost by definition, this means they are
difficult if not impossible to remember
● Passwords are perhaps the worst possible way
of securely authenticating people
● Which is why we are working on ways to get
away from passwords

42.
For now...
● Use Two-factor authentication when offered
(Duo Security, Google, Ubikey, etc.)
● Use a password generator and vault (e.g.
LastPass, KeePassX)
● These generate strong passwords and store
them for you
● This works on the principle of “Keep all of your
eggs in one basket, and watch that basket!”

43.
LastPass
● Made for web site logins
● Available for Chrome, Firefox, Safari, IE
● Integrates with Duo Security and Ubikey for two-factor
authentication
● Can automatically log you in to a site
● Information stored in the cloud, but encrypted first on
your machine before being uploaded (AES-256)
● Requires that you memorize one strong password to
protect your vault

44.
KeePassX
● Stores your passwords locally in an encrypted
database
● Available offline, which is why I store my WiFi
password at home in here
● Having passwords in two places is a good idea
for guaranteeing access to you
● Again, needs a good password to protect the
database

45.
Recommendations
● Right now, in 2014, the best recommendation is
to use long, random passwords
● Since this means they cannot be memorized,
use something like LastPass, KeePassX, or
both, to generate and store passwords.
● I personally use both