I want to prepare two database connection, because in the first one are the stuff for the Website (e. g. Blogs, posts, etc.) and in the other one are the account data.
The account data is in a other database, because it's my authentication database with permissions for FTP, SSH, IMAP etc.
The password is hashed with Mysql function ENCRYPT. So I must create a new Cryptography, Provider and Token. I don't want to change the structure of my database.
(It's FLOW3 Version 1.1beta2)
Very Simple:
I must prepate a seperate database in my mysql database. It isn't the right solution but it is a possibility.
create-server (dev.mysql.com)
Related
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.
I'm writing a content delivery system, which saves data on other companies ftp-server. For that I have to store the connection infos, like host, username, password, … in a database.
I will hash the data and thinking about to save the salts in a config file out of root. But I don't like the idea to write the data to a file.
Is there any better solution to save the salts?
You can try doing it by ssh keys. Client company will generate a pair of keys and upload their public key into your system. Your system can - then - use this public key to establish connection and do it's job.
This way it is easy for them to disable such public key (without changing passwords in all of their related systems). They can set public keys to expire in certain time, and so on. They (clients) should feel more safely about that.
You can store public keys in database, or in files, but using database approach should be easier to protect those keys. Any way... That's your responsibility to protect your database. And that's - how to do it - a totally different question :)
I'm sure you can find information about authenticating using ssh keys for any php framework, and in raw php you can also do it using: ssh2_auth_pubkey_file for example.
I'm wondering how we could hide sensitive data (databases passwords and other passwords) from some developers for our PHP projects. We are using Subversion for our projects. Is it enough to just disallow some users to access the folders where we have the files with the passwords? Any other suggestions?
Do not store sensitive data in any code versioning system. Keep the variables empty.
After first checkout, set the variables locally.
In case of distributed/remote databases, simply create another access for that user to access that database and provide credentials.
Once you set the values, exclude these files from being updated later.
You could have a DB table that stores sensitive data, and only users with right credentials can read from it.
Each developer has to enter username and password to access a DB via some configuration file.
Also you don't need to set user and password for each developer as you can have ie 3 access levels so create just 3 users ie
DeveloperAdmin ( can change password table)
DeveloperTrustedRead (can read password table)
DeveloperNotTrusted ( no access to password table)
So you distribute same db user pass for not trusted dev.
It should be enough.
If you want to implement a cost-effective yet secure way to let different people access the same resource (the password protected one, as a database) with different levels of security, look at this answer Different ways to store a password variable in a Java web application? and implement the option 3 in this way
create multiple usernames/passwords to access the same resource - like another answer suggests a DeveloperTrustedRead, DeveloperNotTrustedRead, etc... role in the database, each with a different username and password. DeveloperNotTrustedRead (for a database) should not create procedure, alter table, drop tables, access other DBs other than the one he operates, etc..
encrypt username/password for each role with a different key in your application (i.e. option 3)
give the untrusted developer the key only to decrypt the username/password linked to the role that has less permissions, like DeveloperNotTrustedRead or DeveloperNotTrustedWrite
This way you can distribute any file in the SVN, as you will be holding the key to decrypt the credentials that matters, while the distributed key will give access to a less powerful/dangerous set of permissions.
This makes sense only if you need them to access the password-protected resource (i.e. a DB) but you are worried to give high privileges to untrusted people, so you want to minimize their permissions for the DB (or any other protected resource) and keep sharing the code easily.
As I have been led to believe, the vast majority of web apps use a single database login credential, typically hard-coded into the app code itself or a secured config file. Application logic and sessions take care of managing user interaction with the database; the database remains ignorant of who is doing what.
However, I would like to take advantage of MySQL's current_user() + triggers to perform certain database actions specific to the individual user. This requires that users make database connections with their unique MySQL credentials. Because the PASSWORD() hashed MySQL password cannot be used to make connections, it is required that the app (1) stores the user's MySQL pwd in clear text in a DB table or ACL file, and (2) stores it in clear text in the session, to be used when making connections. That is not ideal.
Is there a better, more secure approach for doing this?
I have a database that contains user details including sensitive data. They're not as sensitive as financial, but they are sensitive nonetheless. The passwords to the accounts are hashed and salted but the rest can only be encrypted not hashed to allow editing.
How far would you go encrypting the fields? Would you go as far as encrypting everything including generic fields like username, first name, last name, or only fields like address and phone. The first name is used frequently after the user logs in.
Can someone suggest an algorithm (with sample code if available) to encrypt the fields? I use PHP and MySQL primarily.
I wouldn't encrypt the fields at all since it's going to be a royal pain in the rear end :-)
I would instead move sensitive data to a separate table and use the security features of the DBMS itself to protect the data while still allowing access to the non-sensitive data.
In other words, have two tables (user and user_sensitive) tied together with a userID column. Let anyone peruse the user table to their hearts content but access (of any sort) to user_sensitive is restricted to admin-type bods).
And, if my DBMS didn't provide such facilities (I do not know whether MySQL does), I would move to a DBMS that did.
If you want a user to have access to their own sensitive data but not that of other users, we once implemented such a scheme in DB2 by providing a stored procedure. It retrieved all the desired rows but also checked to see which user was executing it. For rows that didn't match that user, the sensitive information was blanked out. The underlying table was fully protected from everyone except the stored procedure itself.
In order for that to work, you would have to be able to run the stored procedure under a different user from the one invoking it. Whether that's possible under MySQL, I have no idea.
I'd google for "transculent databases" - there are both printed books on the subject and some on-line resources.
There are variations of this method but basic idea is to:
encrypt only sensitive fields
encrypt with key from data only the user knows of (like login/password pair)
Password ofc must not be clearly saved in any table. Keys should be held only for session. This way the attacker doesn't have the means to decrypt information whether the database and/or the application is compromised (forgetting for a moment possibility of modifying app code and silently gathering keys).
You want to encrypt the database but still be able to access it using the application. This means that the application needs to have a way to decrypt the data. If the attacker has access to the database, it is quite likely that he will gain access to the application and figures out how to decrypt the database.
You could use transparent disk encryption. However, this only guards against physical access to the disk. It does not add much security if your server is stored somewhere safe.