Currently I am working on php project. The project main theme is to login through ssh to some cisco switch in my local network , fetch details and populate it to user.
To accomplish this I have created on database in MySQL consisting switch login credentials. And my PHP code will fetch the login credentials from database and do it's calculation on switch.
My question is that how can I securely store the switch credentials in my MySQL database to make it secure from any security vulnerabilities.
You hope to store your cisco switch passwords in your database in a form where you can recover the password plain text to use it for ssh connections.
Even if you encrypt the passwords in the database, your program that accesses the database will have to be able to decrypt them to use them. So the decryption key necessarily will be available to your program. That's entirely different from the kind of password-hashing mechanism available in php. Password hashing doesn't allow you to recover the password from the hash, only to compare a user-presented password with the hashed password to see if they match.
Storing decryptable passwords is not secure, and can never be secure. If somebody cracks your server, they then have access to your entire infrastructure. (Cybercreeps with access to switches and routers can really make a mess.) This is the kind of thing that shows up in https://KrebsOnSecurity.com . Don't do it. Please.
If you want more-or-less automated access to your switches via ssh, your best bet is to use ssh's key management features. The machine from which you access the switches will have a private key, and each switch will have a public key corresponding to the private key. If you configure the public keys correctly you can restrict the operations available to users who present the corresponding public keys. It's a big topic, too big for a Stack Overflow answer.
As usual, Digital Ocean's writeup of this topic is useful. https://www.digitalocean.com/community/tutorials/how-to-configure-ssh-key-based-authentication-on-a-linux-server
Typically, securely storing switch (and router) credentials is done with TACACS+, which eliminates the need for hosts logging into the switches from storing credentials beyond those required to access the TACACS+ server.
Related
I'm building a web service and one of the included features involves storing passwords and credentials for users external applications.
My app is built using PHP/Laravel, the current security measures I've implemented are:
Email and password login accompanied by compulsory two-factor authentication using Google Authenticator
Once users are in they need to type in again a master password to access their database of credentials for their external applications.
CSRF Protection and SSL
The passwords are stored in a MySQL database and encrypted using Laravel's encrypt() method and only decrypted (using the decrypt() method) and given to the user if the authenticated users session ID matches the ID in the row with the password credentials.
When a user requests a password credential is it pulled from the database using AJAX, decrypted and copied to the clipboard then deleted from the client side using javascript so the password is only available for a few seconds on the client side before it's back only in the database encrypted as it was before.
Edit: The key for encryption and decryption is Laravel's app key which is a single key stored in the environment file outside of the visible server files in the public folder.
My application is B2B SaaS and is used by mid-large sized clients meaning it needs to be secure. Please point out any flaws you see in my method or any other advice you think is relevant thanks.
The best way to do this is to not do it.
Put another way: If you can get away with not storing passwords (i.e. using OAuth2 instead), don't store passwords. You don't want the extra liability.
That being said, sometimes you literally cannot avoid storing passwords (e.g. IMAP integrations). In this case, always start with a threat model before you delve too far into the weeds.
If someone hacks your database (e.g. SQL injection), what can they access?
Can they access the filesystem and read the encryption keys?
Can they rewrite ciphertexts from a targeted user's account into the field for an account they already hace access to, and thereby gain access to the plaintext without first obtaining the encryption key?
When a user requests a password credential is it pulled from the database using AJAX, decrypted and copied to the clipboard then deleted from the client side using javascript so the password is only available for a few seconds on the client side before it's back only in the database encrypted as it was before.
It sounds like you're reimplementing a password manager. You might want to shepherd your customers towards something like KeePassXC or 1Password instead.
Since this decryption doesn't include any user-provided secrets, the webserver must therefore be capable of decrypting all of your users' passwords. So if an attacker can hack the webserver, they get all of the users' passwords for free.
If you're dead set on partially reinventing password managers, you're going to want to embrace the principle of least authority and make your server unable to decrypt your users' passwords.
This means using client-side encryption, where your server is a black box that only stores ciphertext.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 5 years ago.
Improve this question
I'm currently building a web application(PHP/MySQL) which saves data from persons. Most of this data is not worth protecting with encryption but some of it is financial information like income and so on. It is not a payment application and does not store information that could be turned into money directly like credit card information but still stuff you don't want to have in a possible leak. This platform has to be sold to customers that want "security", but that can mean anything as the customers themselves do not have any knowledge what they really want, since they are business people and not cryptographers(like me neither).
It is a management platform so the people that have their financial data saved there are not the users of the platform. Users of the platform are merely a login with permissions attached to them. The server itself never has to have access the data. Every operation is done by a user(could also be an admin) that is logged in. Multiple users need to have access to the same data given they have enough permissions.
My question is now how I can protect the financial data from these threats:
Somebody finds an SQL-injection and dumps all tables remotely
Somebody steals the hard drive of the server (database + code)
Where I'm certainly not going: Large scale sniffing attack or compromised servers(like sniffing all traffic on the server itself where SSL doesn't matter) or social engineering/phishing.
I would also like to have a quick summary how much more information(keys, data, etc.) I have to store in comparison to the current system, where there is one simple field for income etc. and a standard login system with username and hashed password.
EDIT: Reformulated question almost entirely following the suggestion of comments/answers
Here are two approaches to this:
1) Use symmetric encryption because you have already arranged a secret with the client, which is their password.
Whenever the user requires access to their sensitive information, they need to provide their password. If you require this, then you can use that password as a basis of generating the encryption key.
You can use the openssl functions in PHP to encrypt the sensitive data, and decrypt it when the client needs it. This will allow you to select an appropriately hard to break algorithm which OpenSSL supports. The drawback of this is that you will need explicit user permission and their password to access that data, which is good if you're only storing it on behalf of that user, but bad if you need to pass it on to someone else.
This way you will not need to store additional information in the database. In case someone steals your hard drive, all they will have is encrypted sensitive data and hashed passwords. The drawback is that it's a single point of failure, if they break the encryption they also get the password and vice-versa however the difficulty of breaking the encryption is not as high as reversing a hash. It also relies on strong passwords, which as we know users often don't tend to use, however that's not a new problem and one we're not likely to solve today.
2) Require the user to generate a private-public key pair and send you the public key. You can then store this public key and encrypt data using it. This generally would work well if you had an app/software that communicates with your server, which can do this on the user's behalf, but is harder to implement in a web application. Perhaps there's JavaScript libraries that can do this but since it's not something that is commonly done you need to be 100% sure the library you're using is secure. However this also requires of the user to store the key somewhere and be able to use it whenever they want access to that data (again JavaScript can do this for the user but saving and loading the key is something that requires user interaction due to security concerns).
In short:
Symmetric encryption would only be secure if the encryption key is not stored on the server but is something that the user can provide whenever it is needed.
Asymmetric encryption is even more secure but unrealistic in a web application targeted to an average user.
So I would suggest symmetric encryption using the user's password as a key.
From your question, the following key points stand out.
The server itself never has to have access to the data.
Multiple users need to have access to the same data given they have enough permissions.
Maintain security even if:
Somebody finds an SQL-injection and dumps all tables remotely.
Somebody steals the hard drive of the server (database + code).
This is possible to achieve, but not trivial. The thing that makes this possible is the fact that the server does not require access to the data. This allows us to use user passwords to derive keys.
Each level in your permission structure will have an associated key. This key will be used to encrypt data that can be viewed with those permissions. When the first administrative account is created, generate a key for each level in your permission structure and use the administrative password as an input for a KDF and derive a key. Use this password-derived key to encrypt each permission key and store the resulting ciphertexts alongside the administrative account.
As new users are created and assigned ranks by the administrative account, pull the highest level permission key that the new user will have access to, as well as any keys at a lower permission, decrypt them with the administrative password (which will be required for creating users) and then encrypt them again with the new users password and store alongside the new user in the database.
This system allows you to pass the required encryption keys to each user and makes accessing data above the users permission level cryptographically impossible.
At this point, it is rather straight forward for you to allow users to access data by simply taking their password, decrypting the relevant permission key and then using that key to decrypt the data. Users changing their password is also trivial as it simply means you have to decrypt the permission keys with the old password then re-encrypt with the new password.
At a more technical level, I would recommend the following:
Use AES. AES-256 tends to be the most common but AES-128 is just as secure in the grand scheme of things. Use of an authenticated block mode (GCM) isn't as important here but is still recommended. If not, use a mode like CBC or CTR with an HMAC.
Never use a password directly as a key. Use PBKDF2 to generate keys from passwords. Using AES-256 fits in nicely here because you can use SHA-256 as the primitive to PBKDF2 and get output the same length as the internal hash function.
Generate a new random IV every time you encrypt using a CSPRNG. Prefix the IV to the ciphertext. Don't derive an IV from PBKDF2 like the key.
Asymmetric encryption and hybrid encryption are pointless here unless the users generate and retain ownership of the private keys themselves. I infer from the rest of your question that this isn't the case.
Assuming you want to be able to view this encrypted information without user interaction (e.g. you aren't just storing this information for the user and the information is relevant to your business operations), you have limited storage options.
If your exact threat model is to protect this data in the event of a database leak and nothing else, symmetric encryption is perfect, if properly implemented.
The implication of this is that the symmetric key must be stored on servers that make requests to the database and serve the data to your other (likely front-end) systems. If any of those servers were to become compromised, then the encrypted data will be leaked.
In summary, use symmetric encryption, but understand that it will only protect you directly from a database leak through something like SQL injection or a similar attack. A compromised server is a compromised server and generally means full data access given enough time.
EDIT: If you intend to require user interaction to view the secured data, then apokryfos's comment above accurately details what to do to secure the information. Generate a symmetric key from the users password and use this to encrypt an additional symmetric key. Use this secondary symmetric key to actually encrypt the data. Using two keys makes a user password change easier.
I wrote a web app in PHP, which is processing some secret data, placed in one database table. All fields in this table (excluding id and date of creation) are encrypted with AES, so nobody who has got access to this database can read it.
I encrypt that data with user password. There's no plain password anywhere in database, just the SHA1 sum, so I can verify it. However, I need plain password to decrypt user data when he's logged in, so I store this value in session.
Is it OK for this purpose? If not, what are the good patterns to deal with this case?
I encrypt that data with user password
If they change their password you then have to re-encrypt everything. Look into something more static for the key.
so I store this value in session.
The session should not store this type of information as anyone else with a website on the box (or any other way to access the box) may be able to read it. If your box uses something similar to suPHP or phpSuExec (ask your host) you could place this data in a directory that only your account can access. You could even store it back in the database (encrypted of course).
what are the good patterns to deal with this case?
If security is important to you, go dedicated. If you're unable to do that then at least be on a server that uses suPHP or phpSuExec or the like so that your web server processes run under a unique user so that any data related to the encryption key can be secured.
so nobody who has got access to this database can read it.
By storing your password in the session, you will have a lot of session files in your /tmp directory (or wherever they are stored...) containing users passwords.
Not only does access to your server invalidate your first statement (when you have access to the server, you have direct access to lots of passwords), but someone with server access - even a valid server admin like yourself - can see passwords he or she should never be able to see.
So no, this is not OK.
A possible solution to your problem would be to use an encryption key for the user information that is stored on a different server so that access to the database / database server alone is not enough. However, this is just a thought, you might get a better answer to that question on for example https://security.stackexchange.com/
I find myself in a situation where I have a set of users on a site who all have stored usernames and passwords that allow them to automatically access third party services via SOAP. The idea is that each user should only need to log in to the main site to gain access to multiple services, using their respective stored user info for each service. I feel like such data should be encrypted in my database when stored and then automatically decrypted when it's passed to the php/SOAP function when the user needs to access a given service. What would be the best way to accomplish this?
I've had a look at AES_ENCRYPT, but it seems as though the encryption and decryption makes use of a key that would have to be stored in my code, in plain text...which doesn't seem like the brightest thing to do. Anyway, this is my first time out on something like this (if you couldn't tell); if you could give me some pointers on how I should approach this, I'd really appreciate it.
Many thanks in advance
You stumbled over the biggest problem with encrypting data in the database:
➽ Where to store the key?
Encryption cannot solve the problem of securing data, it can only "concentrate" it to a key. Wherever you store the key, your application must be able to decrypt the data, so can do an attacker. There are two possible solutions to this problem i know of:
Place the key in a place as secure as you can. That means, it should surely be placed outside of the www-root directory in an inaccessible directory on the server. Depending on the importance of the data, you can also consider to outsource encryption to another dedicated server.
Don't store a key at all and derive it from the user password. This is the only really safe way, because not even the server can decrypt the data then. The cons are of course, that the user needs to enter the password every time he uses your service. If the user changes the password, you need to re-encrypt all data. If the user forgets the password, the data is lost.
P.S. I would recommend to encrypt the data before storing it to the database, because MySQL AES_ENCRYPT uses the ECB mode without an IV. This allows to search for a certain value, but is less secure (i'm pretty sure that you don't want to search by password).
I have an interesting encryption problem at hand. I do not know if it can be solved but here goes:
A database is to contain sensitive user information. As such, the user information must be encrypted (two way encryption). The user has a login / password and these may be used in the two way encryption. Now, the encryption is to be designed in such a way that even the administrator viewing the database tables should not be able to make sense of the user information.
However, the design has to take care of the cases where the user may forget her password. If the password is used for encryption, forgetting the password means the information is lost - not wanted. If the user password itself is stored in the database using a two way algorithm (instead of a one way hash) with a key hardcoded in the script, the administrator can discover the hardcoded key by looking at the script (the administrator of course has access to the script).
Does anybody know a way out of this?
PS: This is a real problem. My company is an absolute security fanatic (ISO 27001 and all) and I have been entrusted to design a system with the above mentioned functionality. By the way, I am using a PHP script and MySQL.
EDIT: Perhaps it was not clear earlier, the user needs to see / edit this user information on a day-to-day basis.
What you want is a recovery agent. Encrypt all data twice: once with the user key, once with the recovery agent (public) key; atleast the latter one needs to be asymmetric. Keep the recovery agent key in a pyhsical safe, with a formal access protocol (e.g. four eyes principle). Usually, the administrator cannot access the encrypted data, but if the user loses the key, and recovery is authorized, then the recovery key is obtained.
There are also ways to encrypt the recovery agent's key so that m-out-of-n people have to agree to use it.
Edit: One implementation strategy is to encrypt everything twice. Alternatively, for each data set that needs to be recoverable independently, create a fresh symmetric key, and encrypt only that key twice; the original data get encrypted only with the session key. That approach can extend to multiple independent readers; it requires asymmetric keys per reader (so that you can encrypt the session key with the public keys of all readers - one being the recovery agent).
I copied the terminology from Microsoft's Encrypting File System, which has that scheme implemented.
Can't be done.
In all cases, someone has to be able to recreate the key to decrypt it. Let's consider the options:
Key stored on server. Fails: administrator has access.
Key encrypted with user's password. Fails: user might forget it.
The solution is to relax the administrator having access restriction, and instead of impossible, you make it just very difficult. For example, if the data were encrypted with a key stored encrypted with the user's password, but that key were escrowed in some other system which can't be accessed in the normal course of events by the administrator (perhaps only another admin has access?) then you can still recover from a user forgetting their password (with intervention of whoever has access to escrowed keys), but the admin can't just download your database and read all the data.