John's Blog: Storing Passwords Using Strong Encryption

November 18, 2016

As a bit of a geek, one of my favorite features of Rumpus is the ability to choose how passwords are stored. Security-conscious administrators probably shudder a bit (perhaps rightfully so) at Rumpus offering the option to store passwords in plain text, but it's a very useful option in some cases on servers where security is not a major concern. But right now, I'd like to focus on strong password encryption, and how clever it is. (For those keeping score, I'm not the clever one... I may have implemented it in Rumpus, but the technique is well-known, commonly used, and was invented by people way more clever than I.)

The Rumpus.users File
Rumpus maintains user accounts in a simple, tabs-delimited text file, called "Rumpus.users". (On Windows, it's in "C:\Rumpus\Config\", and on the Mac, it's in "\usr\local\Rumpus\", a folder that can most easily be accessed from the File menu by choosing "Open Config Folder".) That file can be opened in a text editor, spreadsheet, or other application, and can be reviewed, modified or added to, should you decide to do so. Since it's such a straightforward format, though, anyone with access to that file can easily see every user account defined in Rumpus, and potentially their password.
Hopefully, your server and it's config files are kept well locked down, both in terms of physical access and services running that might give unexpected control to remote users. But what would happen if someone were to gain access to your Rumpus.users file?
One Way Only
When Strong Password Encryption is enabled in Rumpus, when you create a new user account (or change the password of an existing account) Rumpus immediately sends the new password through a one way encryption algorithm. In other words, the password is "hashed" into a completely different string of characters, and there is no way to decode that string of characters back into the original password. It is this seemingly random string that is then saved in the Rumpus.users file as the user account password.
At this point, it's important to understand that even internally within Rumpus, there is now no record of the actual password for any user account. In other words, even Rumpus doesn't know what the passwords are for it's own user accounts.
So how, when a user attempts to log in, does Rumpus determine if the password entered by the user is the same as the password assigned to the account? Simple... Rumpus takes the password submitted by the user and sends it through the same hashing algorithm. If the resulting string of characters matches the stored string for that account, the passwords are a match and the user is granted access.
In short, The Rumpus service does not know the password of any user in the database, but is able to determine if the password attempted is correct anyway. As I said above, clever!
The Benefits
With Strong Password Encryption enabled, you could actually hand your Rumpus.users file on a platter to a potential hacker. With that file, they would be able to see the user account names, the paths to those user Home Folders, and the privileges they have on the server. But they would not be able to log into your server, because even though they would be able to readily view the "hashed" password string, there is no way to return that string back into the password needed to access the server.
This is an important protection, because it prevents would-be hackers from "escalating" attacks. In other words, were someone to gain very basic read-only access to your server, they could potentially access the Rumpus.users file, and the information there could easily gain them the escalated privileges of any Rumpus user, including the administrator. In this case, a small problem could become a big problem quickly, but is thwarted by one-way encrypted passwords.
The Drawbacks
The basic drawback, and the important thing for an administrator to be aware of, is that passwords can never be recovered. If a user forgets their password, they can't simply call you up and ask for a reminder, because it is technically impossible for anyone, even the system administrator, to retrieve a password. In this case, the correct procedure is to set a new password for the user and communicate to them the new password.
And even if at some later time you decide to set the password storage method back to a simpler method, those user account passwords that were encrypted will continue to be encrypted, since (again) it is simply not possible to go back to the unencrypted password. If you revert to plain text (or weakly encrypted) passwords, you'll need to manually reset passwords to have them saved that way.
But even these drawback are really strengths. In secure environments, administrators really shouldn't be able to view user passwords. While it's not a good idea, some users use the same password on multiple services, so an administrator who can look up passwords may be able to gain access to other, totally unrelated services, which is certainly problematic from a security standpoint.
In the end, using Strong Password Encryption can be occasionally inconvenient, but the security benefits are significant and well worth the effort for anyone who requires even a moderate level of security. Plus, as the computer geek in me will tell you, it's a system that's clever as hell.

© Copyright 2017, Maxum Development Corp.