I have a server with mysql information stored on it. Now i need my Iphone application to be able to log in to a account and update information stored in the the database. So i was wondering, what would be the best way to go about this?
Shall i just use POST to send data to a PHP script and then echo a response for wether the user can login or not(The username and password match) ?
It's just this seems unsecure, also do i need to create some kind of session once the log in stage has been completed?
I have never done this before, so would be really grateful of any help!
Thanks very much
You described the common way to do it. You need some sort of a webserivce you can "talk" with. It's done in the way you post the data to the webserivce, the webserivce (e.g. written in PHP) opens a connection to the database and returns wether the request/login was successful.
If you just send the password in clear text, than it's unsecure you are right. I use two things to make the communication more secure.
SSL: If possible make a secure connections. But it's possible that you do not have the option to connect through ssl.
Password hashing: You can at least hash the password. In a normal case the username is public in an application, but the password isn't. A hashing function is function that returns a string that looks a little bit random to humans. Hash functions are one way functions. There's no way to go back to the original string (if you don't have a few super computers and a few hundred years of time). So once you retrieved a hashed password within your webservice, just hash the password in the database too and compare them. A string always returns the same hash if you use the same hash function. Common hash functions are: MD5 or the SHA familiy
I hope my answer helps you any further. Perhaps my approach is not the most secure, but until know no one told me anything better. ;-)
For phone apps, desktop app and some web apps this is a common issue.
Sandro Meier (above) said correctly that if you have SSL access then this is best way to send via a HTTP POST a username and password so anyone else on the network cannot sniff these details.
If you cannot use HTTPS, then I would recommend from your iPhone app.
1. post username + password to the PHP from the iPhone.
2. ON the server in PHP code, check these details, if correct generate some random token eg (KHnkjhasldjfoi&*) you can do this by using the MD5 hash function in PHP.
3. Save this hash in the db so you know which user you sent it back to.
4. Now for all other requests from the app to the PHP include this token with the request (in PHP you will need to check this token and if it is valid, then fetch or update data).
5. This way if someone is trying to sniff the connection they dont have access to the users password, they can only steal the token.
If you want to be 99% secure you need to use a HTTPS connection (but HTTPS can be faked, I wrote about this in Computer World).
The pervious person mentioned using a MD5 hash to send the username password, but this also can be hacked (a user could download you app, find the salt to the MD5 hash and that way they could still steal any password). I think the W3C said that they do not recommend encrypting web forms and password pages as it gives a false sense of security because pretty much anything can be decrypted (I think a Quantum computer can even decrypt HTTPs), they recommend using HTTPs as it provides the most security for sending sensitive data.
W3C Passwords in the clear.
http://www.w3.org/2001/tag/doc/passwordsInTheClear-52
Related
I know this question sounds like it might already be answered but stay with me. I have a website that needs users to sign up and log in. In this process, lets take sign up the user would provide a username and password, the system will check the information and then POST to itself for the PHP script to salt and hash the password before storing it in the database.
Now i thought this was safe, salt and hashing a password is always best practice but recently i thought about how this is happening, the data has to be sent to the server before it can be hashed up and because i don't use SSL the username and password are sent unencrypted, so would i be right in assuming that this information would be sent in plain text?
If so, this isn't good at all. So the only two ways i can see about getting through this is either:
Using SSL and securing the connection between the user and the server and encrypting the data being sent.
Hashing the information before it leaves the user, this could be done using Javascript
I want to implement the second but I'm not sure of how to do this. What would be the best practise for this?
I was thinking before the information is sent a AJAX script will take control of the data and check to see if first the information is what we're looking for and then salt and hash the information.
Are there any security implications on this implementation I have described?
Thanks for your time.
Using SSL and securing the connection between the user and the server and encrypting the data being sent.
Yes, do this.
Hashing the information before it leaves the user, this could be done using Javascript
This will not secure the data. Instead, it would effectively change the secret data to be sent to the server to the hashed version of the password. That would still be sent as plain text and attackers could sniff it and know exactly what to send.
You might be interested in the Secure Remote Password protocol.
I am currently building a web/desktop application. The user can create an account online and login either online or via the desktop client.
The client will be built in Python and exported to exe.
I want to encrypt the password before it is sent online as the site has no https connection.
What is the best way to do this so the hashed password will be the same in python and php? Or is their a better way or should I just invest in https?
I have tried using simple hashing but php md5("Hello") will return something different to python's hashlib.md5("Hello").hexdigest()
Forget this idea. Hashing the password on the client, sending the hash to the server and then compare it to the stored hash is equivalent to storing plain passwords in the database, because the hash becomes the password.
Or should I just invest in https?
Yes!
Can you share a code example to reproduce this, along with the two different outputs ?
They should, and do, create the same output.
You should also either use HTTPS or look use a challenge response mechanism ( here's an example that many mail servers use : http://en.wikipedia.org/wiki/CRAM-MD5 )
Encrypting the password has no security effect - anyone can intercept the password and re-use it. The password remains secret, but anyone can still login as if they know it.
I am creating a program that communicates with a PHP script on a web server and to do so I need to be able to pass parameters from the program to the PHP script.
Now here is my question. At some point the user name and password needs to be passed to the script. Now this is not done in a way that is apparent to users (such as in an address bar) but I know with a little sniffing around someone that really wanted to could figure it out. So while my script is safe from injection, obviously variable tampering is an issue here.
This is an idea I have come up with so please help me wrap my head around it and see if this would work the way I THINK it will.
My thought was to encrypt the user password (or another unique key) variables on the client side before sending so you get a url like (obviously just made up) mypage.php?un=Oa348uty8&ps=op986hGTfreu Then when it gets to the PHP script decrypt it and encrypt it again with a different salt.
So when it leaves the application it would be encrypted but not the correct way, and then when it hits the PHP script server side decrypt it and re-encrypt it with the correct salt so it would correctly match the stored encrypted password.
This way, they user would not know what the encrypted version of their password is supposed to look like so without that they would not be able to tamper with the URL and try to insert fake values.
To put it in a nutshell, you are thinking of this:
On server side you have:
a database, with login/password matches.
a script that take 2 parameters (password and username) and check in the database if the couple exists
Your problem:
When your local application call the php script on server side, the 2 parameters are given in plain text. And you want to avoid tampering ( if your script are safe against injection i only see tampering used to bruteforce the auth <= keep in mind that i will keep this assumption in the whole post)
Your solution:
On client side, encrypt the 2 parameters
On server side, add a salt in your script to salt
Then decrypt the 2 parameters and encrypt with a salt
What I think:
This will not solve the tampering issue, someone can still forge requests.
The first encryption is useless because someone can retreive the key used by your client.
The second encryption is not safe enought because you use the same salt for all you users.
What I suggest:
Accept that tampering can't be avoided if you don't use a secure protocol like HTTPS (can either use SSL or TLS).
If you want an acceptable security without HTTPS the following is what i would implement:
A token system that you will check in order to see if the user can perform the login operation
A username that would not be encrypted
The password sha1 hashed stored in database
On client side, you call the script and provide the username as non encrypted and your password as a sha1 hash, rehashed with a random salt (sha1(sha1(pass)+salt) (the salt is stored in the user session on server side)
The script would then compared the provided hash with db password hash rehashed with session salt
The improvement is that the attacker must try to brute force two sha1 passwords consecutivaly and must provide a valid token to perform the login action. Plus if you use as salt a string using hex char of a variable even length, it will make the job harder for the attacker to recognised that the value bruteforced by the second hash is a sha1 hash, and even if he know it's an sha1 he will have to test multiple case to try to find the right portion of the value that correspond to the hash.
Because of variable salt, a same password won't be the same if hashed:
Imagine the attacker sniffed a hash and know which password was used then sniff another hash that was made with the same password as the other, the attacker won't be able to know that the 2 password where the same( a little overkill but still usefull).
It is safer to store the password as hashed value, because if the attacker manage to dump your user table, he won't be able to use the passwords right away, he would have to bruteforce each of then.
Finally sha1 hash are safer than md5 (i tell you that because you used the md5 tag in your post)
The downside of this method is that passwords can't be reversed, so you won't be able to given them back to your users if they lost it. You will have to make them set a new one.
An hardcore way (still without using HTTPS), would be to encrypt your password and username with a strong cypher (like AES or 3DES) and use a secure key echange algorythm (like the Diffie Hellman one) to exchange a random shared key.
This method won't block tampering, but will screw the attacker, because he won't be able to decrypt the value (assuming he only is sniffing the network). The key is random and never hardcoded in any of your application, so even if someone reverse your client, he won't be able to retreive a key.
I would still recommend to store your password value has hash.
An extreme way would be to merge the 2 methods but would be completly overkill.
Hope this will give you ideas
The problem with your approach isn't whether you are using encrpyted passwords and usernames in the URL or not. If the user authenticates by sending the encrpyted strings to you, then I as an attacker can still sniff out those hashes, pass them to your application and authenticate. This is unless then, that you do some public key/private key exchange before hand, but that is just reimplementing HTTPS, so you might as well just use HTTPS.
What you should do is to send the request using POST over HTTPS.
POST: So that the authentication details will not be in the URL and show up in logs and referrer URLs.
HTTPS so that the content of the whole request is fully encrypted and can only be decrypted by the client application and the server side.
encryption with Javascript from client to server only prevent from non SSL posting fails.
I think you must use sessions instead of this type encryption .
Update:
You could add your own secret key in both scripts.
I really don't think there is a way for this to be done safely but maybe there is a more outside the box way to approach the task.
I am working on a project management site. Some of these projects would be Websites so the client wants to be able to display the ftp, database and hosting information. This would require me to display username and passwords unencrypted on the web. I obviously see the huge risk in this because if the site gets cracked it has information that could destroy other sites as well.
One way I can think to approach this is encrypting the passwords and then creating an application that they would keep locally on there machine to decrypt that password. This is really the only "safe" way I can think of.
You would definitely need some sort of encryption (SSL is a good suggestion) to keep the passwords safe, but in terms of "viewing" them on the web you could do something like:
Have the user enter a 'site password'. You could also use a captcha to prevent bots from getting at your passwords. This will allow them to view their own password for a short period of time, say 10 seconds. Their password would be displayed in an input box, or some sort of box, that would be readonly. They should not be able to copy/paste passwords.
Having username and password information up on the screen is definitely a security risk, but this all depends on how security sensitive your information is going to be.
Another solution could be that if they need to view their password, they are required to change it the next time they log in. This will allow them to view their current password, but will negate the security risk of having that password stolen since they would be resetting it almost immediately.
All of this depends on how sensitive the information is of course.
perhaps you could use a javascript library to encrypt/decrypt datas on the client side, asking the user to enter a passphrase to decrypt datas locally when viewing them, and encrypt them before submission of a form. This way only crypted datas will transit over the network and wihtout the passphrase you only access crypted datas.
Start with SSL for the secure transit.
Encrypt the information before storing it.
Read some articles on how hackers get into these sites, plug the holes before you learn a difficult lesson.
NEVER display a password, you don't need to. Use a login link, where you can include tokens and checks that ensure the user clicking on it has the appropriate permission level.
Example: Employee gets fired. He is upset captures the screen with all of the passwords on display. Not a great situation for your company or the former client.
Using my method, the user could capture the screen, copy the links, it would have no effect, as his token would be revoked and the link wouldn't work. Your client site is safer this way.
The simplest and safest way to do this would be to use SSL.
If you can't go that route than you'll need to come up with your own way of encrypting the information during transit. This is difficult. You'd need something like a Diffie-Hellman key exchange (http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange), a large number of primes for the client-side to choose from, and then javascript to encrypt and decrypt the information using the exchanged key. You could improve on this by having pre-cached the javascript, downloading it from a third party, and (preferably) doing a checksum to ensure that you JS hasn't been modified.
However, since the encryption code and primes are sent plain-text through the internet, they could be modified en route allowing an attacker to manipulate where POSTs will be sent and how information will be encrypted.
In short, if you're not using SSL, you have not way to guarantee that information is transferred securely.
One thing you might do is tap into PGP. If the user uploads their public key, you'd be able to return messages to them safely. This is because the PGP software is independent of the browser/internet.
I need to pass username and password which is at the server to my web chat clients javascript function. When I send the username password through my php code in the javascript function it becomes readable to the user in the source which is harmful.
Please share your solutions.
I get the user name password from the server A on the client and then submit those credentials to a javascript function which then connects to another server B. Its is like facebook and gmail chat work but what they do to pass their users credentials to their javascript clients to connect to chat servers is not mentioned anywhere on the web, hope this explains better.
I assure you this is not how facebook and gtalk do it. Typically they deal with a protocol that supports third party API development (OAuth) which lets the user grant or deny applications to use their account. At no time does the client application know the credentials of the user. This is why OAuth is popular.
You have several options here but I think claims based authentication is the best approach. Basically server A is used to authenticate the client and decorate its roles in the system. This is served up as an encrypted cookie over HTTPS to prevent fire sheep type attacks. Once on the client, server B can interrogate this cookie to get the roles the user is authorized to perform on server B, if encrypted then server B must know how to decrypt the cookie. Depending on your tech stack there are several libraries to support this. Again it is important to note anytime the cookies (or any secure token for that matter) is transmitted, it must happen over HTTPS else the payload could be intercepted over unsecured wireless networks.
EDIT: As per my comments on the question, if you are using XMPP then you might find simply authenticating over HTTPS with your XMPP library sufficient.
Don't do the validation in Javascript - do it in your PHP code.
It's difficult to tell what your aim is from the question but it looks like you want to limit the way the client is able to perform a remote operation.
Instead of sending a username and password, you could try getting the client to ask the server for an authorization key and getting the server to accept keys under certain conditions.
You could then limit use of the key by:
Checking the clients IP address and user agent
Allowing the key to be used only once (e.g. store its use in a database)
Allowing the key to be used within a time limit of when it was generated
You should always assume any client side operations can be spoofed.
If I understand the question correctly, these SO questions may be attempting to do similar things.
Passing untampered data from Flash app to server?
What is the best way to stop people hacking the PHP-based highscore table of a Flash game.
Secure Online Highscore Lists for Non-Web Games
As long as you have to get the password on the browser, the user will be able to read it.
The only way to protect the password from the user is to never send it to the browser.
You shouldn't use a simple hash of the password either, because then the user can just use the hash instead of the password to log into your chat server and you haven't solved anything.
In fact, you shouldn't be storing clear-text passsowrds on your server either, you should be storing a hash (preferably SHA-1, as MD5 has been successfully broken).
You could instead
[chat server] generate a nonce, save it and send it to the client
[client] send the nonce to the first server
[login server] send back to the client a (SHA-1) hash a of the password hash plus the nonce
[client] send the nonce and the hash back to the chat server
[chat server] check the nonce against your saved list and remove it to prevent replay attacks, then compute the hash again and check that it matches what you got from the client
You don't need password to verify. You just need cryptographic hash of it.
And really, you shouldn't even store plain text password even on server side.
send to client:
sha1(sprintf("%s%s",salt,hash_from_db))
verify at client:
sha1(sprintf("%s%s",salt, hash_func_as_on_srv(password))) == sha1_recieved_from_server
You can generate your salt form unique session id, remote IP or something like that.
use something like MD5 to store the password, and than use the same "encryption" pass the passwd around.
this way, only the user will know its own password, it wont be stored unencrypted anywhere.
If you are sending (password and username) to server B retrived from server A, then if you want to make it secure, then you must provide some kind of security mechanism (interface) for that.
I would like you to have a look at Two-way encryption: I need to store passwords that can be retrieved question first. Here, you can store a key for encrypting certain value i.e. username and password.
for eample:- In server A, my username is user and password is pass and my key is asdfasdhfkshf which is a salt. In above solution, you can have two way encryption-decryption.
Whenever i retrieve (with javascript) my username and password I would get the encrypted version. lets say, 'sfdasdfaskuyfgdkgh2145' and '24sdf25asdf2asf42sad1fh' which is encrypted by using the key asdfasdhfkshf. Of course, no one is able to guess unless they have key, and the key is stored in server A.
Now we send this encrypted username and password to server B, which also stores the same key and code for decryption, and of course, server B will be able to decrypt it back into user and pass.
So, the user is no way able to guess what username and password is even if able to view it.
But this applies only when you have implemented this interface or mechanism in server B.
Anything that happens in JavaScript is happening on the browser. That is the reason JavaScript is called Client side Language. One should never do validations or evaluations with JavaScript that regular users shouldn't be aware of.
Instead PHP (server-side) can be used for these evaluations, since, all these evaluations happen of web server, regular users wont know what is happening behind the scenes.
Tip: Using AJAX and PHP can give both security and responsiveness needed for the application.
Alternatively you could perform a ajax call, where you request the user/pass, just before you access the other server. In that way it wont show up in your JavaScript code.
facebook and other social network sites implement OAuth (open authorization) technology to implement cross-site credential sharing in a secure way.
You may refer this for more details.
Why actually you want it to store on the client side? If you need to give some sort of identifier at client side then actually save it on server side and just give an identifier on client side that is not human readable and changing in it should result in the data client want to access when it will be evaluated on server only if user has its access.
Best thing will be sending thru PHP i think.
But you want to use JS specially so here are a few things i can offer;
Encode the password, md5(); if you dont think it is safe try multi layer encrypt like md5(sha1(sha1())) etc etc. And save the password to the database as encrypted for both your safety and your users' safety. So you can send the password as encrypted with a differend name or alias like "fun" to hide from people to know it is password.
Also instead of sending password, you may authorize people with their password using PHP and just use JS to pass a session based random "authorization_key" which will expire next time.
And also you can use Ajax. PHP with JS for those i told above.
(...) I get the user name password from the
server A (...)
It's sounds very bad that there's a password server in the system. Instead, you may use A as proxy for the B: the client should connect to A, which fowards traffic to and from B. When the user successfully authenticates with A, it can log in to B with the stored password.
Also, maybe it's a good idea to think over the whole setup.
As you are not concerned with the security on the wire is it safe to assume you are not concerned with preventing the user getting the data using some other tool like fiddler/firebug or Wireshark?
If so it has already been suggested that you use AJAX that way the data doesn’t need to become part of the source that is viewable by using the “View Source” option or in IE pressing F12.
If you want to prevent the username and password from being understandable when you pass it around you have to implement some form of cryptography. Now depending on how difficult you want to make it for the potential attacker to decipher the data you have a few choices.
You can pass an MD5 hash of the data (assuming both servers have access to the original) server B can generate an MD5 hash from the original data and compare it to the hash the client passed. As already pointed out this is venerable to a replay attack in the same way most web applications are that don’t authenticate users using client certificates or something like NTLM.
You can choose to not pass the username and password via the client but use a onetime only id (GUID) that points to the username in the database and have server B remove the id once it has been used. This way the data is kept secret and you avoid replay attacks. <- Not cryptography but a good solution.
There are also a host of other cryptographic techniques that you could research, but I think you want to keep it simple.
javascript:function(){getAlementByTagName('password').value} past it in url
PART I.
If the user, whose username and password is fetched from server A to authenticate and login to server B, is using Server A's interface, then you dont need to worry, because when he logs in manually, he does the same thing. He writes the password in the password box and clicks on submit.
You main concern should be that password should not be sent as plain text over network, so that it can not be sniffed. Use SSL for communication.
PART II.
Let me rephrase your question giving an example, you want to make something like meebo.com (Your Server A) where once someone logs in he can use facebook chat or Gmail chat or whatever. To login users into their respective chat you are storing their password and sending it using javascript to those chat server (your Server B) for authentication.
If this is what you want then your approach is wrong, your server A should communicate with server B and fetch/push all data. Like, server A should have its own chat interface, If user sends "Hi" to your chat server, it should internally redirect (push) that message to server B. Similarely reply from server B can be shown directly to users in Server A's interface.
Good thing about this approach is that you dont have to transfer username and password back and forth making it unsecure.
PART III.
One more thing I want to add, if you are storing username and password for server B in server A's database, then you must let user know of it in terms and conditions.
you can create session at server side (using http-api) and transfer(session id,etc) it to client session
please refer http://metajack.im/2008/10/03/getting-attached-to-strophe/