Salt your passwords!

Not so long ago it was common to see passwords stored in databases in plaintext. Major corporations were even guilty of this (do a google search for “web hosting stored passwords in plaintext” to see what I mean). Thankfully it appears that developers have finally realized it’s better to code something the safe way the first time rather than suffer the repercussions of shortcuts. As a result, the instances of this occurring are quickly dwindling out of existence.

These days there’s a phenomenon that’s arguably just as dangerous: hashing unsalted passwords. 

Let’s imagine a scenario where a malicious individual has managed to acquire a copy of user records from our web application’s database. Three records have been chosen from our “user” table:

ID	Name	UserName	Password
198	Martha Robinson	mrobinson	0ce8d8fccd5e6071fdab1a4edec504872ad338dcf34920f5b5baedfb9a74da91
237	John Davidson	jdoe	0ce8d8fccd5e6071fdab1a4edec504872ad338dcf34920f5b5baedfb9a74da91
599	Sarah Smith	ssmith	ca74e5fe75654735d3b8d04a7bdf5dcdd06f1c6c2a215171a24e5a9dcb28e7a2

All passwords in the table are hashed once using SHA-256.

You might be thinking, these passwords are hashed, so what’s the problem? One of the defining traits of modern day hashing algorithms is that the slightest change in the source string will drastically change the generated hash from that string. For instance, take a look at the hashes for ‘Football123’ and ‘Footballs123’ (respectively): 

0ce8d8fccd5e6071fdab1a4edec504872ad338dcf34920f5b5baedfb9a74da91
f77211f25d1f3bafd92ca23085d583f230c9febe6fc4e45a2e5ef0592c68f2e5

See that? By just changing the “Football” part in our plaintext password to plural “Footballs”, there’s a huge difference in the appearance of the two hashes.

The first thing the hacker is going to do is try and crack Martha and Johns’ passwords. Why? The two hashes are identical to each other. Thus, the attacker will deduce from this that those hashes were calculated from the same exact passwords.

Now the hacker knows that Martha and John have identical passwords. This is a big problem – what are the chances they both happened to think of the same extremely complex and secure passphrase? Not very likely.

What we need is a way to ensure that even simple passwords – even ones like Martha and Johns’, will at least appear unique in our db. This is where salting comes into play. What we do is generate a “random” string of characters and mix those in with our plaintext source passkey. 

So in our above example, instead of hashing ‘Football123’ which results in: 0ce8d8fccd5e6071fdab1a4edec504872ad338dcf34920f5b5baedfb9a74da91

We can take a random string like ab9FlmNO!!, concatenate it to the end of our ‘Football123’ text and hash that instead which yields: da2c1d31cb17f8a7fc13a7e49f392c99dcee1f6bd863ba266abf28ed1aa0e9f9

Or maybe we have Football123Lc87nHNm!? Which becomes: b2cf5569f2fd345218c4670431d32b3a5ea38ec3a02a719973f73b5d9d25a130

And now even if someone else comes along with the same password, they’ll still end up with a unique hash.

The orientation of the salt doesn’t really matter – you could place it at the end, at the beginning, in the middle of the string, wherever. As long as your back-end code knows how to apply the salt to the given plaintext password prior to hashing, you’re good. The main point is adding extra characters to the passwords to make their hashes more distinguishable.

In terms of storing those salts in the database, we could simply add on another column to our user table that could contain the hash. The next time a user tries to log in, our system looks up the corresponding salt hash, adds that to the user-provided password, hashes them together, and if that hash matches the pass in the database, then the password is correct.

If the salt is blatantly exposed in the database as well, then doesn’t that render this security measure useless? No, this makes it increasingly more difficult for our attacker to be able to identify those who have weak passwords simply by visual inspection. The hacker can easily see Martha and John’s salts, but won’t be able to discern quickly that they have the same passwords. Sure, it would be much better if the hash wasn’t exposed to begin with, but that isn’t feasible as our application needs some way of being able to tell what that salt actually is. We could also have a global salt that would be used by every user, which could be encapsulated within the application and unknown to database. This would present its own set of drawbacks as well. There's no 100% "safe" solution. We're just making this as secure as we possibly can.

Although salting is a powerful safeguard against brute-force and dictionary attacks, it’s far from being the only tool you’ll want in your arsenal of security mechanisms if you expect your application and its data to withstand modern day exploits. That said, it’s an invaluable technique that builds a strong starting foundation for proper password storage. Salting is a critical step that must not be overlooked during the development process.

Reversing a Linked List

Reversing a singly linked list is one of those things that’s super easy to implement but can be tricky at first to actually implement – especially if you’re new to linked lists in general. At the same time, it’s definitely an algorithm that you should understand. Besides there of course being use cases for it in dev related purposes, it’s also the focus of common teasers that you’ll find in interview questions. Simply put, regardless of whether or not you have an immediate need to utilize this algorithm, it’s one that any coder should have handy in their back pocket.

The goal of this post is to make it as clear as possible for you to grasp and visualize the method of linked list reversing. As you read along you might find it helpful to also watch the following video (as the example in the video is the same as talked about in this post):

Let’s start with a very simple singly linked list:

Yup, nothing fancy about this list. Four integers are linked together (1 -> 2 -> 3 -> 4) –  1 at the head of the list, 4 at the end. What we want is for the order to become reversed: 4 -> 3 -> 2 -> 1 – putting 4 at the head of the list.

Let’s get into how we’re going to set up our reversal code. We’ll assume that we’re writing a function which accepts a ‘pointer’ to the head of the linked list. At the beginning of our function we’ll initialize 3 pointers: previous, current, and next. These pointers will be used so we can keep track of node states during the reversal.

ListNode previous = null;
ListNode current = head;
ListNode next = head;

Our previous pointer is currently set to null. This makes sense because we haven’t even performed 1 iteration of our reversing loop, so why would previous be set to anything? Then we set current to head – even at the start we’re positioned at the head aka first node, so current should be set to something.  Finally we got our next pointer, currently set to head as well, and, as long as head wasn’t null to begin with, will ensure that the below while loop runs at least 1 iteration:

while(head != null) {
}

Easy enough so far, right? Now we have to start to work out the code we’ll have inside our loop.

Let’s pretend we’re just starting and running for one iteration – the second line of code within our loop is going to overwrite the next pointer on our current node, but we’ll need to reference that pointer later on so we can keep traversing the linked list – so we’ll store and preserve that in next for future use. The following line will set next to point to node1:

next = current.next;

Now we get to the part where we’re actually linking our current node up to our previous node. At this stage, current is referencing the head node (node1) and we’re going to link node1’s next up to prev (right now being null).

current.next = prev;

Now we’ll update prev so that it references current (so prev will point to node1):

prev = current;

And then finally we set current to next (in this case current will point to node2)

current = next;

By the end of the iteration, node1 will point to null, and we’ve set our pointers up so that we’re ready to work on linking node2’s next to node1.

I mentioned earlier that in this scenario were writing a function which will return the value of the new ‘head’ node. As for our return value – what are we going to return to represent our new head? Just by visually inspecting the animation we can see that it wouldn’t make sense to return either current or next since by the end of the process both of these will hold a null value. We’ll have to return prev since that will always contain the last item in the list right before null.

Putting it all together, we have the following reversing method in java (which, being as simple as it is, is easily portable to other languages):