APPLY TESTING TECHNIQUES FOR SOFTWARE DEVELOPMENTICTPRG529

SESSION 7 OVERVIEW

Database password security (not assessed)

• Storing passwords in a database

• The problem with storing passwords as plain text

• Password encryption

• Password hashing

• Salting a hash

• Assignment work

Security

• If you will be working with databases that have user authentication via logins

such as those on websites or in large businesses, this is an important topic

area covered because we have in our work so far, stored passwords as plain

text (this is bad).

• Security is an issue that changes regularly as new methods and cracks are

implemented and exposed. It is a large and dynamic topic area that requires

constant revising and researching. The minute you think you know it all, is the

minute you became vulnerable. Research yourself the latest methods and more

complex methods such as bcrypt using the foundation knowledge you gain

here.

• This method discussed will protect against an SQL injection attack by a hacker

who is after the passwords of your users. This will not prevent an SQL injection

attack, but if one does happen, this method discussed will protect you.

Preventing SQL injection is covered elsewhere in another unit when you do

some PHP coding.

• Note: Part of being a good database or web developer is to be paranoid.

• Email addresses as usernames for logging into a website can be a good choice as:

1. email addresses are unique

2. people remember their own email address

• Storing passwords as plain text in the database as below is a bad technique

Usernames and Passwords

Encryption v Hashing

• Encryption is the process of converting data to an unrecognizable form.

• Used to protect sensitive information so that only authorized parties can view it.

Encryption’s purpose is to transform data and to keep it secret from others.

Encryption is reversible i.e. something that is encrypted can be later decrypted if

you know the key. Encryption is used in web browsers when someone uses

HTTPS instead of HTTP. HTTPS will encrypt something, send it across the internet

as gobbledygook, and decrypt it in the browser at the other end so the receiver

can understand the data. HTTP however will just send the data across the

internet as plain, open text that anyone can read if they intercept it along the

way.

• Hashing is a form of encryption, but it can only go one way - it is one directional.

Once something is hashed, it cannot be ‘unhashed’ back into its original format.

• Using hashing to change our passwords stored in the database from plain text to

hexadecimal gobbledygook, instead of storing ‘waterspout’ in the database, we

will store its equivalent SHA256 hashed value of

‘ecabadf0e06b0496faefe85662ec19779280aeede3508e77abb47a8324f0ebb0’.

• The same passwords as previously stored in the GlobalHolidays Guests table in a hashed SHA256 format are:

Hashed passwords stored

• They cannot be de-hashed back to their original plain text words

How do we check the password on sign-in?

1. When the guest Kelly Thomas (GuestID 3) wants to log into our GlobalHolidays website, they type ‘

tkelly@firehosesareus.com.au’ as their username and ‘waterspout’ as the password (the website will use email

addresses as the usernames for signing in).

2. The PHP, .NET, Java, or whatever programming language is used on the website passes an SQL query to the database

with the email username exactly as it was typed, however the PHP, .NET or Java will hash the password using SHA256

to change it from ‘waterspout’ to ‘ecabadf0e06b0496faefe85662ec19779280aeede3508e77abb47a8324f0ebb0’ and

pass that over to the database. A likely SQL query passed over to the database for Kelly Thomas trying to log in with

their correct details will be:

select GuestID, FirstName, LastName, CountryID

from guests

where email = 'tkelly@firehosesareus.com.au‘

and password = 'ecabadf0e06b0496faefe85662ec19779280aeede3508e77abb47a8324f0ebb0';

• So even though Kelly Thomas typed ‘waterspout’ as their password into the website, the programming code hashes it

and the hashed value is what is used in the SQL query. In other words, when Kelly Thomas first joined our website, we

do not store ‘waterspout’ as their password in the database. We stored the SHA256 equivalent of it in the database i.e.

‘ecabadf0e06b0496faefe85662ec19779280aeede3508e77abb47a8324f0ebb0’. ‘waterspout’ was never stored in the

database and never will be. Whenever Kelly Thomas wants to log back in, we are comparing the hashed equivalent of

what they type (waterspout) i.e ‘ecabadf0e06b0496faefe85662ec19779280aeede3508e77abb47a8324f0ebb0’ to the

value in the database.

• A word will always hash to the exact same string of characters everytime it is hashed i.e. ‘waterspout’ will always hash

to same value using SHA256 (hexadecimal output) i.e.

ecabadf0e06b0496faefe85662ec19779280aeede3508e77abb47a8324f0ebb0

• Try hashing ‘waterspout’ with SHA256 on these websites:

http://www.xorbin.com/tools/sha256-hash-calculator

https://quickhash.com/

http://hash.online-convert.com/sha256-generator

The problem with just a hash

• SHA256 hashing still has a security problem

• People use poor common ‘strings’ for passwords

• This creates a problem because a value will always SHA256

hash to be the exact same hashed value every time. This

combined with people being predictable with their

passwords, a hacker can try the hash of ‘123456’, in an SQL

injection query attack, with many different email addresses

and eventually crack their way in.

• Research ‘rainbow table’ for an explanation of how hackers

can use CPU computing power and rainbow tables to force

their way into websites.

• A computer can hash the entire English dictionary in

seconds.

• A hacker tries to get into websites with the hashed value

instead of the original plain text value.

Most common passwords (splashdata.com)

1. 123456 (Unchanged)2. password (Unchanged)3. 12345 (Up 17)4. 12345678 (Down 1)5. qwerty (Down 1)6. 123456789 (Unchanged)7. 1234 (Up 9)8. baseball (New)9. dragon (New)10. football (New)11. 1234567 (Down 4)12. monkey (Up 5)13. letmein (Up 1)14. abc123 (Down 9)15. 111111 (Down 8)16.mustang (New)17. access (New)18. shadow (Unchanged)19. master (New)20. michael (New)21. superman (New)22. 696969 (New)23. 123123 (Down 12)24. batman (New)25. trustno1 (Down 1)

Adding salt to the hash

• Salt:

- a random unique value used with the hash to create an even more difficult string

- for each user in the database, it is stored alongside their hashed password as plain text

• We can’t make people use good passwords. To protect against SQL injection attacks, on our user’s passwords, by hackers using

hashed rainbow tables, we need a way to make sure that if our guests use bad passwords such as ‘123456’ or ‘qwerty’ or ‘password’,

whenever we hash the value of one of them, it doesn’t always work out to the same hashed value i.e. if 4 people have the same

password of ‘123456’, then when we hash it, we end up with 4 different hashed values. Using just SHA256 without a salt, would leave

us with 4 identical hashed values for ‘123456’ of

SHA256 hash (‘1234356’) = ‘8d969eef6ecad3c29a3a629280e686cf0c3f5d5a86aff3ca12020c923adc6c92’

i.e. every person with the password ‘123456’ would have in the database the same hashed value as their password.

• If instead of just SHA256 hash (‘1234356’), we hash ‘123456’ + random string ‘j39je&3#PZM2*’ tacked onto the end of it, we end up

with:

SHA256 hash (‘1234356j39je&3#PZM2*’) = ‘82e634edbc049d547eeff9b0fa5ab7350f4e2cbb472750d7f04e995fe235ebd1’

• If we hash SHA256 hash (‘123456’) + a different random string ‘po28HG5%#@Cva’ tacked onto the end of it, we end up with a

different result:

SHA256 hash (‘1234356po28HG5%#@Cva’) = ‘0bcbde24270165fc72adfa1cc881fd7631879ac1b7bd8d1774a6a7854242b1fa’

• So for 4 different users having 4 different salts added to their original passwords, we will end up with 4 different salted hashes:

SHA256 hash (‘123456j39je&3#PZM2*’) = ‘82e634edbc049d547eeff9b0fa5ab7350f4e2cbb472750d7f04e995fe235ebd1’

SHA256 hash (‘123456po28HG5%#@Cva’) = ‘0bcbde24270165fc72adfa1cc881fd7631879ac1b7bd8d1774a6a7854242b1fa’

SHA256 hash (‘123456iwkHG%*76);km’) = ‘f6d1b7d16228094737f4e99ec4d7f15f3ade658820ee2abf568da6aefcc841f3’

SHA256 hash (‘1234566431dawj&@<kq) = ‘51e24cd141737b094140ba3e4a5663df14eab9a912945347e4ee6530c214ef95’

• When a user types their password into website, we go to the database, look up their email address to get their salt, add the salt onto

the end of the password they just typed into the website, use PHP (we’ll learn in anther unit) to SHA256 hash this ‘typed password +

salt’, put this result into our SQL query to see if it matches the password stored in the database for that user.

• We have made much more difficult, any SQL injection attacks on our user’s passwords by hackers using hashed rainbow tables of

commonly used passwords

An example from GlobalHolidays• In the Guests table both Jackson Kelly (GuestID 9) and Paul Springsteen (GuestID 18) used the same

password of ‘password’. By using a salt, we can end up with very different hashed values being stored

for each of them. The hacker might be able to guess the username and work out the hash of the original

password, but they will not be able to easily guess the username, salt and hash of the

salt+originalpassword. Note: the original password is never stored in the database in its original form

Because of the salt being added, the 3 different users with the same password end up with a different

hashed value stored as their password

• SHA256 (passwordH62olwd^@G) = 98d8d49b5729f3411f6dbae87ff763be4a4f0baeb3f824207bc96f54ba899d5f

• SHA256 (passwordkwUY^$6hsWqM9) = 5f7e6a87fc9dcdd6b998779683fdb3807623192920c00e16fa61d30fb116846f

• SHA256 (password!79qHAM[&9uTg) = a154f7671900b452fd01d3f7f10fcd0573a29d1c2c241d93f70949effca11787

GuestID FirstName LastName Email Salt Password3 Kelly Thomas kellyt@firehosesareus H62olwd^@G 98d8d49b5729f3411f6dbae87ff763be4a4f0baeb

3f824207bc96f54ba899d5f9 Jackson Kelly jfk8484@gmail.com kwUY^$6hsWqM9 5f7e6a87fc9dcdd6b998779683fdb38076231929

20c00e16fa61d30fb116846f18 Paul Springsteen theboss@tapking.com.au !79qHAM[&9uTg a154f7671900b452fd01d3f7f10fcd0573a29d1c2

c241d93f70949effca11787

Hash(Salt + password) – a visual view

Global Holidays relational database mud map

Global Holidays normalised tables

GlobalHolidays database:Countries (CountryID, Country)Cities (CityID, City, CountryID)Guests (GuestID, [FirstName], [LastName], [Gender{M,F}], [CountryID], JoinDate, [Email], [Password])Hotels (HotelID, HotelName, CityID, [ParkingSpaces], [PetFriendly], [JoinDate], [HotelViewDesc])HotelPhotos (HotelPhotoID, HotelID, HotelPhotoName, MainDisplayPhoto{Y,N})BedTypes (BedTypeID, BedTypeDesc)Rooms (HotelID, HotelRoomNum, BedTypeID, [RoomDesc], [StandardPrice], [Sleeps])Bookings (BookingID, GuestID, HotelID, HotelRoomNum, Checkin, Checkout, [NumGuests]) Notes:- Table names are in bold- Primary keys are underlined- Foreign keys are not explicitly labelled as foreign keys- Columns that can have NULLS i.e. it is optional to enter data in them, are in [square brackets]- Columns where the data entered can only be one of the listed alternatives are in {curly brackets separated by a comma} e.g. Gender {M,F} means a user can only enter a ‘M’, or a ‘F’ (M=Male, F=Female)

The Global holidays database data (1)

Cities

Hotels

Countries

HotelPhotos

The Global holidays database data (2)Rooms

BedTypes

The Global holidays database data (3)Guests

Bookings

ANY QUESTIONS