Concealing a Fixed Password
November 24, 2011 2:25 PM Subscribe
A software application needs to supply a fixed password to an outside hardware device that it talks to. How can that password be concealed from hackers who take apart the software or the computer it's running on?
How would you achieve a situation where the application "knows" its password and is able to supply it, but the password never shows up as a string in the source code, or in a config file, or in memory.
The application needs to run in an automated way, so prompting a user to supply it is not an option.
Encrypting the password just seems to push the problem down the line: the encryption key then needs to be stored somewhere.
How would you achieve a situation where the application "knows" its password and is able to supply it, but the password never shows up as a string in the source code, or in a config file, or in memory.
The application needs to run in an automated way, so prompting a user to supply it is not an option.
Encrypting the password just seems to push the problem down the line: the encryption key then needs to be stored somewhere.
Store the encryption key on a different server. The device pulls the encryption key from the server decrypts and sends the key to the hardware device. A Hacker then needs to break into two different machines in two different locations to use the hardware key .
posted by Poet_Lariat at 2:40 PM on November 24, 2011
posted by Poet_Lariat at 2:40 PM on November 24, 2011
You use password hashing and the device stores only the hashed value of a password. This password is supplied, then the device applies a mathematical function to it (RSA, etc.), and the resulting hash is compared to the stored one.
posted by rhizome at 3:07 PM on November 24, 2011
posted by rhizome at 3:07 PM on November 24, 2011
You use password hashing and the device stores only the hashed value of a password. This password is supplied, then the device applies a mathematical function to it (RSA, etc.), and the resulting hash is compared to the stored one.
But if you're submitting only the hash to the device, then the hash effectively is the password and you still need to store the hash.
posted by atrazine at 3:15 PM on November 24, 2011
But if you're submitting only the hash to the device, then the hash effectively is the password and you still need to store the hash.
posted by atrazine at 3:15 PM on November 24, 2011
kindall's answer is correct, here's why:
Let's suppose the password is encrypted and stored on the system running the application, its presence is therefore not in plain text. You specify that the authentication must be performed with no user input. In this case, the key and algorythm for decrypting the password must also be stored on that system. However, to supply the password to the remote device, your system must first decrypt the password, THEN send it on; it will necessarily be in memory, if only for a short time.
Even were you to have the user enter the password, it would be stored in memory in plain text at first, because the system must read input from the keyboard to memory in plain text before it is able to encrypt/hash the entered text.
Remove 'in memory' from your requirements and this will become feasible. If your need to control access to the device is critical, you need to start thinking about defence in depth, two-way authentication and man-in-the-middle attacks.
posted by fearnothing at 3:34 PM on November 24, 2011
Let's suppose the password is encrypted and stored on the system running the application, its presence is therefore not in plain text. You specify that the authentication must be performed with no user input. In this case, the key and algorythm for decrypting the password must also be stored on that system. However, to supply the password to the remote device, your system must first decrypt the password, THEN send it on; it will necessarily be in memory, if only for a short time.
Even were you to have the user enter the password, it would be stored in memory in plain text at first, because the system must read input from the keyboard to memory in plain text before it is able to encrypt/hash the entered text.
Remove 'in memory' from your requirements and this will become feasible. If your need to control access to the device is critical, you need to start thinking about defence in depth, two-way authentication and man-in-the-middle attacks.
posted by fearnothing at 3:34 PM on November 24, 2011
On linux you can put it in a folder that only the user running the process has access to. But that wouldn't stop anybody with root access from getting to it.
posted by empath at 4:11 PM on November 24, 2011
posted by empath at 4:11 PM on November 24, 2011
kindall's answer is wrong, here's why:
Any password/encryption scheme can be broken.
Any one. Period. There is no unencryptable scheme. None.
Your only defense is to make the cost of decryption far costlier than the worth of the data obtained.
So it does not matter that a particular scheme can be potentially broken. What matters is the cost of breaking the scheme. My suggestion to place the an encrypted key on a different machine merely adds to the time and effort of breaking into the system. An infinite number of usable strategies can be employed. You could , for instance, simply encase the machine running the software application in a highly secure area, or put it in a safe and bolt it to the floor. Whatever.
Your job as architect is to devise a system such that cracking the system costs far more than the value of the data obtained.
posted by Poet_Lariat at 4:13 PM on November 24, 2011
Any password/encryption scheme can be broken.
Any one. Period. There is no unencryptable scheme. None.
Your only defense is to make the cost of decryption far costlier than the worth of the data obtained.
So it does not matter that a particular scheme can be potentially broken. What matters is the cost of breaking the scheme. My suggestion to place the an encrypted key on a different machine merely adds to the time and effort of breaking into the system. An infinite number of usable strategies can be employed. You could , for instance, simply encase the machine running the software application in a highly secure area, or put it in a safe and bolt it to the floor. Whatever.
Your job as architect is to devise a system such that cracking the system costs far more than the value of the data obtained.
posted by Poet_Lariat at 4:13 PM on November 24, 2011
Kindall is correct, although a secure dongle or outside server may solve whatever unstated conditions are driving your question. If this is an authentication/licensing issue, you may be able to tie the product activation to a particular mac or ip address also.
posted by BrotherCaine at 4:15 PM on November 24, 2011
posted by BrotherCaine at 4:15 PM on November 24, 2011
You specify "hackers who take apart ... the computer it's running on". Does this mean the hackers might have physical access? That would open other huge avenues of attack — they can intercept the password on its way to the hardware by replacing a cable or what have you.
posted by stebulus at 5:17 PM on November 24, 2011
posted by stebulus at 5:17 PM on November 24, 2011
Transport Layer Security (used to be called Secure Socket Layer) with large keys and varying encryption salts (presumably from the application side) can make encryption difficult computationally expensive enough to not be worth the effort of trying to break.
posted by thatdawnperson at 5:20 PM on November 24, 2011
posted by thatdawnperson at 5:20 PM on November 24, 2011
Transport Layer Security (used to be called Secure Socket Layer) with large keys and varying encryption salts (presumably from the application side) can make encryption difficult computationally expensive enough to not be worth the effort of trying to break.
Isn't that something that would need to be implemented on both ends of the authentication? The question statement that the hardware device needs to be supplied with a "fixed" password suggests that its method of authentication is not configurable.
posted by juv3nal at 5:34 PM on November 24, 2011
Isn't that something that would need to be implemented on both ends of the authentication? The question statement that the hardware device needs to be supplied with a "fixed" password suggests that its method of authentication is not configurable.
posted by juv3nal at 5:34 PM on November 24, 2011
The 'dongle' answer above, with actual dongles or smartcards that are tamper-resistant to your level of comfort might be the answer, unless there's additional issues the 'hardware device' brings to the table.
posted by graftole at 5:48 PM on November 24, 2011
posted by graftole at 5:48 PM on November 24, 2011
Everyone here is somewhat 'right'. If you're trying to protect against an attacker with physical access to the system there really is no protection. Against a remote attack it's still not theoretically possible but certainly may be made very difficult for an attack to succeed. Build a very secure system overall using a hardened OS with all the very best practices and a solid plan to keep it up to date, good password management, good network management. Then use good practices when coding the software. Do just the basic right things (still a lot of work) and you'll have something that will not be an 'easy' target.
posted by sammyo at 6:06 PM on November 24, 2011
posted by sammyo at 6:06 PM on November 24, 2011
If you store an encryption key within the app, then at some point that key will exist in memory (such as when decrypting assets). There's no foolproof way to protect this information in source, also. One thing you can do to discourage cracking is to obfuscate it, so that hackers will have a more difficult time distinguishing your obfuscated encryption key from random noise. But keep in mind that, once any one person has cracked the key, it is game over for all copies of that app.
posted by Blazecock Pileon at 11:22 PM on November 24, 2011
posted by Blazecock Pileon at 11:22 PM on November 24, 2011
Response by poster: Thank you all for the help in thinking this through. It seems like relying on physical security is the way to go.
posted by Paquda at 8:02 AM on November 25, 2011
posted by Paquda at 8:02 AM on November 25, 2011
Don't use a symmetric password... use public-key cryptography.
Instead of transmitting the password, transmit a response to a challenge.
posted by teatime at 6:57 PM on November 28, 2011
Instead of transmitting the password, transmit a response to a challenge.
posted by teatime at 6:57 PM on November 28, 2011
« Older Stick with my awesome CRT or take the plunge for... | Good indie horror/sci-fi films, on Netflix instant... Newer »
This thread is closed to new comments.
posted by kindall at 2:31 PM on November 24, 2011 [4 favorites]