I am developing a website that connects to a users MSSQL database to collect information. Users are assigned to different MSSQL database accounts and connect to them using the IP, username and password stored inside the MySQL DB.
Currently, what I've got is PHP the AES encrypts/decrypts the passwords as needed. That just doesn't seem right. It prevents you from seeing the plain text password by looking in the database (which is undeniably good) but I'm not sold on it's level of security.
Hashing is great and all if you never need the password again, but I do. So I don't really know how to go about implementing a reasonable level of security into this particular aspect of the site.
Any suggestions would be great. Am I completely wrong and being an idiot. Is there a vastly superior way to do this?
Obviously if you are sending the password over to MS SQL, you are going to need to be able to reverse the value. I would think encryption would be the most correct answer here. Either way your code will still be able to extrapolate this password, otherwise you cannot connect.
If you would like to increase the security, you can seed your encryption with a checksum calculated from the user name... however, if the user name ever changes, you will need to decrypt and re-encrypt. This will only make it a bit tougher for "others" that may know you are using AES.
But at the end of the day, you will always be able to know what the password is, since you need to decrypt. There is only so much you can do in this situation, the best would be to demand the password from the user every time it's needed.
Related
I'm building an application using php for server side code, at the moment the customer has a shared server with linux and a mysql database (yes I know it is an horrible solution, but they don't want to spend more money).
The problem is: they asked me to store their email addresses with relative passwords in the application, so they can contact their customers from different addresses without inserting password everytime, but my problem is: how?
I mean, if I use one-way encryption it'll be more secure, but I have to ask password everytime to verify, two-way encryption is more comfortable, but not safe.
Two-way encryption would be the way to do this. If the customer doesn't want to have to insert the password, then the system has to be able to.
But this is okay. Because these are not user passwords. These are system passwords. They can be as complex and difficult to remember as you want, because they are literally never typed by a user. They wouldn't be re-used by the same user on other systems (which is one of the most insecure things about user passwords and why it's dangerous to be able to read them).
The technical concern here is minor, just use a good encryption on the data at rest (the database where the passwords are stored). The actual concern here is one of educating your customer and advising them of how this works. The passwords are retrievable, so they should be as random and unusable as possible.
As the title says I'm trying to use PHP's password_hash function but I know that it is one way hashing so if I use it the password will be unable to be unhashed.
That being said, I want to be able to have an eye next to a password box (like LastPass) within the system that I'm working with that can display the password for admin users of the site but I'm not sure how to do this. Is there a function within PHP or some library that will allow for secure hashing or encryption so that this is possible? Is there another way to do this securely?
I've been looking around stack overflow for a while now just trying to find an answer to this but have to find anything that is close to what I'm wanting to do.
For a quick frame of reference for this. The users of the site can allow for 3rd party companies to login to retrieve files that are being shared with them. The users create the password and share it with the 3rd party. I want to make sure that when the passwords are secured but still allow the users of the site to go back and lookup the password for the 3rd party companies should they forget their password.
... that will allow for secure hashing or encryption so that [displaying the password for admin users] is possible?
You keep using that word. I do not think it means what you think it means. :-)
Password hashing can either be secure or it can be reversible.
The whole point of password hashing is to be non-reversible. If you want the original password, you're going to have to store it (keeping in mind how insecure this actually is).
At a bare minimum, you'd want the plaintext password somewhere totally separate from, and inaccessible to, the outside world. But the ground is littered from the corpses of password files that companies thought were secure from the general public, so my advice is to steer well clear of this.
No, you cannot get the original plaintext password from a hash. That's the entire point. The plaintext password is a secret that only the user is supposed to know. The secrecy of their password is the only security measure they have. If the password is "publicly" known then the security is out of their hands. And if anyone besides them knows the password, even if it's just your server, it becomes harder and harder to control who knows the password and it's only a matter of time until it leaks entirely.
That is why you don't want even your server to know the actual password, and to only store an irreversible hash of it.
If you want to store the password in a way that is reversible, at the very least you should store it such that even the server itself could not see the plaintext. Meaning, even if you encrypt it, encrypt it in a way that the server itself cannot decrypt it. Because if your server can decrypt it, so can anyone with access to that server. For instance, use entirely client-side encryption within the browser and require the user to enter their password in some way which will decrypt the stored password. Of course, this limits who will be able to see the password, which is the entire point.
If you need concrete encryption schemes to design this, it's best to ask at http://security.stackexchange.com or perhaps https://crypto.stackexchange.com.
I have a website which is a front end to a MySQL database. This data is also exposed via a web service (fur use in Android application).
Currently I am maintaining the data via PHPMyAdmin but this is cumbersome and not that "pretty".
I want to create an /admin module where I log in (against values in a PHP Varialbe or a MySQL table) and once logged in I can edit,delete,add data.
Questions:
Is it acceptable in terms of security to compare entered credentials against static variables? There will only be one user so I feel like it is overhead to create a table for members.
Any guidelines on going down this route?
I don't see any reason why you couldn't do it this way, assuming you will always have just the one user. The main consideration would be if someone somehow got a look at your code, they would see the stored password. So, you could store it using password_hash to generate a one way hash, and then verify it with password_verify. Here's how I might do it:
Using password_hash(), generate a hash:
// copy the hash output, then delete this code
echo password_hash("thepassword", PASSWORD_DEFAULT);
Then, in your code, store the hash:
// paste hash here
$passwordKey = '$2y$10$j33UPA7gNxSOBsXQcyquLOZRuO6X8k8hZOb1RA79iN8gLlqp9eIPO';
Then run password_verify() to check the user input:
if (password_verify($userInput, $passwordKey))
echo "correct";
else echo "incorrect";
Demo: http://3v4l.org/PknTI
consider looking at this manual for encryption methods with php. My gut instinct is to make a user table, or at least a table with just the encrypted password in it, rather than just checking the variable against a value.
That being said, if you don't think anyone will really even consider trying to fool around with the system and get past it, you probably don't need to be this cautious. I've built a few front-ends as well as back-ends to communicate somewhat friendly with a database, and I've never experienced a considerable amount pressure on the security.
Hope this helps, if you have any questions about how I've designed the ones I've made, feel free to email me at spencer#codeshrub.com
If phpmyadmin is installed at your server localy, than it is NOT securely at all
You can use any MySQL client that supports ssh connection. E.g. Sequel Pro for Mac or HeidiSQL for WIN.
Also, you can use basic HTTP Authentication for you admin script. But, since it's very simple it's not protect you from bruteforce or password leaking, etc.
Anyway, if you prefer security you need to make your own authentication in PHP, You can use this package for example. It is simple and has many security features
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).
What to use for password security ?
Being a newbie at this (and coding in general), I've been looking at all sorts of different tutorials, articles etc. about PHP and security concerning passwords. This resulted in all sorts of different solutions, when using a mysql db and php. The unfortunate things is, that all of these different articles and / or tutorials seem to contradict one another. Some say md5 is fine for the "mainstream" user, others recommend sha1 or crypt(). Now, as far as I can see, only crypt() seems like a "viable" solution. Using md5 doesn't exactly seem safe, having all sorts of different online decryption sites. Using sha1, even with a salt, doesn't seem any better. A short demonstration is given here:
http://www.youtube.com/watch?v=lrGMxH8WNZ8
All of this leads me to my question. What would be the best solution for a mysql driven forum site ? It doesn't, in principle at least, contain any "personal information" (couldn't remember the correct english term). Is it necessary to make some SSL solution or......?
Thank you.
Everyone is going to tout bcrypt which is solid. but i prefer the new PHP5 API password hashing function which is standard in php 5.5.
read about it here
It is super easy and from what I can tell super secure.
Just set up a 60 length varchar in your db and your set
$hash = password_hash($password, PASSWORD_BCRYPT);
and to verify:
if (password_verify($password, $hash)) {
// password valid!
} else {
// wrong password :(
}
Since not all hosting servers offer 5.5 you can get the class here
As far as SSL goes, it is recommended.
md5 and sha are not to be used really - http://www.php.net/manual/en/faq.passwords.php#faq.passwords.fasthash
Also, whether you store boring non sensitive info or government secrets, you should use the most secure methods. What if your site plan changes once all this is implemented and suddenly you DO need to store sensitive data?
What if someone hacks your non-sensitive database through insecure methods and wipes everything? It may be nothing more than a pain losing all that data and having to restore form a back up, but for me this in itself is enough.
Also, as someone has hacked your DB, what if they return later and do it again, you'll end up having to update your login methods anyway.
Adding to that, why not learn best practice from the start then any site you do is best security approach? Why learn simple and not-so-secure methods for one site to learn a different way for another later?
Learn best practice, always, and always use it then you only need to learn and use one method throughout all your code and thus from practice makes you more efficient and knowledgeable with it.
A combination of crypt and Blowfish is pretty much the way I go now. It takes user password from registration and spits out a hashed string and unique salt together, always same char length so you can manage it in a database easily.
All users salts are different so someone obtaining all your DB data and working out how one password salt is formed, which is barely possible, gets only one password and in no way the method to obtain others.
Then when user logs in, you simply use the built in function to check their inputted password from login form to the one in the DB and the library works out the hash/salt/etc and checks the two. If match log them in, otherwise not.