Imagine that the user has a password “stack overflow” entered during registration on the website. The website will split the password in two, the first part being always four characters long:

Part 1: "stac"
Part 2: "k overflow"

Then some random characters are appended to the first part, and prepended to the second part, given that the prepended part is of a given length, let’s say 6:

Part 1: "stacd9u8BHaI1"
Part 2: "hBy47k overflow"

The first part is salted and hashed on a first server and stored in the database. The second part uses a different salt, different hash, and a database on a different server.

Imagine a hacker gains access to the first database and successfully finds, for example through brute force, the password “stacd9u8BHaI1”. The hacker tests this password on the website, and notices that it doesn’t work. He may be discouraged by that, and abandon the tentative of finding other passwords. It’s supplementary security, given that it’s not extremely strong, but still valuable if it doesn’t cost too much in terms of resources compared to the ordinary, single server authentication.

Isn’t it easy to discover what part of password is stored?

Actually, no. It’s possible, but not easy. If you find, through brute force, that the original password is “hBy47k overflow”, you may guess that the beginning was randomized, but it’s not straightforward. Random characters may also be adjusted accordingly: for example for passwords which contain only words, a word may be prepended/appended, instead of random characters:

Part 1: "stac battery" // Appending a random number of characters
Part 2: "change k overflow" // Prepending 7 characters

or:

Part 1: "stac white unicorn"
Part 2: "global k overflow" // Still 7 characters

You actually need to brute force several passwords to guess how much prepended/appended characters are there.

When it fails?

There is a case when this technique fails miserably: if you have an account on a hacked system, you already know your password, so by bruteforcing the two parts, you can easily see what parts were preserved. Making the number of characters in the first part and the number of characters prepended to the second part dependent on an element relative to the password itself makes it more difficult to understand the system, but still quite doable.

Do I need to implement this system right now?

No. Security which relies on the fact that you keep secret the way you store passwords is weak. Anybody who has an access to the source code knows all the elements.

The split the password technique has a tiny advantage, but still doesn’t worth to be implemented in every website. Just use PBKDF2 with correct parameters, and you’ll be fine. Even if you’re a bank. I’m pretty sure my bank stores my password in plain in the database, as well as most websites you use daily. That sucks.

In this article: http://www.technologyreview.com/news/429498/to-keep-passwords-safe-from-hackers-just-break/

I´ve read that both servers have to rely on different security mechanisms, so if one system gets compromised the second might still be safe and the intruder gets only half of the password. But this is not a complete answer because I don´t know which security mechanisms get used there.

This isn’t for database passwords. That requires you to re-assemble the password, and since your one machine knows how to do that, attackers can just get that machine and win.

This is for user authentication. When someone submits a password, you split it and send it to two auth servers who reply yes/no on the two halves. This doesn’t prevent someone from doing a dictionary attack, but does prevent the whole password from being stored in one location.

It is effective and common solution in physical world security – two keys to a safe, two PINs needed to access a room etc – Server admin passwords stored 1/2 each in two locations. Many movies make good use of it for dramatic effect.

How this translates to servers – Like the physical world, the added complexity means reliability for legitimate access can be reduced, (i.e. two people need to be at the same place at the same time and a car breaks down compared to two servers need to (securely) talk to each other and the comms fails.)

Where the differences between real world and servers is that putting a gun to one persons head does not help with the other guy – you need to have 2 guns one for each head… Unless done simultaneously – the compromise is detected and the attach will fail. This needs good coordination and planning, and the the key to this scheme working.

Essentially for this to work you need to ensure that an attack (successful or not) on one system will not assist an attack on the other. The attacker must also not be able to successfully attack both systems “simultaneously” – so the sooner you can detect a successful attack – the less likely it is to succeed. On top of this – you need to be certain that maintaining two systems does not reduce the security of either system compared to if you maintain a single system.

At this point there is a lot of probability math and crystal ball gazing to really know if it’s worth it. It’s not something that will be successful if done on the cheap and with little though, but it is a way to increase security when done properly.