I am making a program like yelp. Some people have some accounts. So I got to send the password to the web.
Should I encrypt the password before sending it?
After that what would be the standard password policy others used?
Should the encrypted password be the one stored on the mySQL serve? In other word, there is absolutely no need for decryption?
Basically it's like What encryption procedure I must use to send encrypted 'email' and 'password' values over the HTTP protocoll? but for objective-c
After the user logged in, my program need to tell the server that the user is authenticated already. Does my program need to keep sending password?
There are more than one architecture you can implement, and you have to choose considering many factors, like performance, how many users, server architecture...
Basically, you must use https and not http, store hashed password (MD5, SHA, ecc.) and always check if hashed password is equal to stored hashed password.
You can implement also a "session" using token (you have to create a kind of API server side and then use it on client side) or pass username and password in each call to web service (web service must verify credentials every time is called).
Another "fast" (it's not so fast anyway) solution is to implement (both server-client) a standard protocol like (it's my favorite) oAuth 2. It's used by twitter and Facebook, you can learn more here: http://oauth.net/2/
You might be looking for Base64 encoding:
http://cocoawithlove.com/2009/06/base64-encoding-options-on-mac-and.html
Related
I am planning on creating a little web service to host on my site, but I would like to know how to create a simple, secure login form (username + password) for just one username + password combination, without using SQL. This doesn't have to be super-secure, but it would be nice if you couldn't just crack it by peeking at the source code. Can this be done?
You could just use Basic Auth?
http://en.wikipedia.org/wiki/Basic_access_authentication
You can use Berkeley DB. It is a key-value database that is stored in a file. It does not have a server, but it supports concurrent access. Just make sure to put the file outside of where your webserver will serve it (in other words, not next to the CGI script that users are accessing).
Edit: The asker clarified that he wanted something extremely simple to implement with a "limited understanding of web design". In that case, put the username and password in a text file (plain text, JSON, CSV, whatever your programming language can parse the easiest) in a place where your webserver won't serve it, and make it readable only by the webserver. You should also hash the password (that link is for PHP, but it will be very similar in other languages).
Do you have some kind of server-side scripting? It's not possible in JS.
Since you said it doesn't need to be completely secure, you can basically use hashing and salting to create something which can't be "cracked" by looking at the source. Be aware that if you aren't connecting over https, a malicious users in your local network, ISP, government, etc will able to eavesdrop on the communication and see you transmitting a plain-text password. For this reason alone, the password shouldn't be re-used anywhere and the implications of someone else logging in should be low.
Here's a crude example of how to generate the hash:
<?php
$salt = "can-be-anything";
$password = "password";
$hash = hash_pbkdf2( "sha256", $password, $salt, 1024, 0 );
echo $hash;
?>
and our result is 5b24ad89b5e94c35537f6967b39cf294aa845f94440ebfdd3e857e4cf5f41d7e. Now you can just follow the same procedure when receiving the password and compare the two hashes. If you reduce the number of iterations it will be easier to brute-force the hash, but will reduce server load.
Pros
Can store the hashed password inside the same file
Someone looking at the source can't learn your password
Complexity to break the stored password scales with password length
Cons
No guarantee of security, someone could eventually gain access
If not using https, an attacker could learn your password from passive network monitoring
You can also use an OAuth provider (facebook, google, twitter, linked in) and even enable two step verification.
It's really easy to set up, here is an example on PHP using google:
https://github.com/google/google-api-php-client/blob/master/examples/idtoken.php
And here another using facebook:
https://github.com/facebook/facebook-php-sdk-v4/tree/f1916f3a1e8aeece518a18dc88f05775aadb9840/examples/login-logout-get-profile
Both google and facebook have apis for all major languages, but you can also use any standard oauth client if you prefer. Or even implement you own one, the client is actually fairly simple.
I'm trying to set a cookie so that user can be automatically logged in.
I do not want to query DB for session string when authenticating cookies (basically I need to do that whenever most of my APIs are called, I want to make it faster)
the solution I found is to set a hash in the cookie and try to decrypt it when authenticating, if decryption is successful then log user in.
I am wondering what hashing method should I use? Do I just use a constant salt in my program and hash the userName with that salt, store the hashed userName and original userName in cookie, and try to match userName with decrypted hash upon authentication?
Since I am not familiar with hashing functions, can anyone kindly provide some suggestions on how should I do it in Java?
I recommend you to use an unique token key generated for each session. For example, if a client once logged in from a computer, this token will be valid until the password is changed. Expiring a cookie is not completely secure...
You can also use session variable for a simple authentication. Once you set a session variable for an user, every time this user sends a request with this session id; your session variable will be reached for just this session id. Most of the platforms can also use DB for storing these variables for you.
Two approaches:
1) Create your own authentication framework. In this case I recommend to put in a cookie an encrypted value of a username (I strongly not recommend to use hashing; also please do not put the user password value). For encryption please use AES-256 encryption with BouncyCastle:
256bit AES/CBC/PKCS5Padding with Bouncy Castle
If your framework success to decrypt the cookie – the user is authenticated. If your framework cannot decrypt the cookie or the user is not exist - the user is not authenticated.
2) Please consider to use the Spring Security framework:
http://static.springsource.org/spring-security/site/docs/3.1.x/reference/springsecurity-single.html
It is the great framework and solves a lot of authentication / authorization problems.
Your problem is solved by the “RememberMe” feature:
http://static.springsource.org/spring-security/site/docs/3.1.x/reference/springsecurity-single.html#ns-remember-me
Best regards,
Michael
I don't come from Java background, but your hash key should never be something exposed.
For example:- In your case UserName is key and one of the fellow developers who knows what mechanism you are using can break it down because name is something very common and known.
Don't know what the best way is but I have used UserID(GUID) which is not visible in UI.
I'm currently making some research on the WSSE protocol to secure my api.
I've understood the basis and it is clear in my head.
However I face to a problem.
Let's say I want to generate a ONE-time Digest, I've to concatenate the timestamp, the nonce and the secret password.
However, on the server side, I don't have the clear password stored in database, so I'm unable to check for the digest.
Switching to clear password is not an option.
I can't either provide to the client-side the algorithm used to hash password, because they use salt, and the salt is not available to the client.
The only solution I can think about is to don't hash the Digest, just concatenate the data and base64 them.
That way I'll be able to encode the user password to check for its validity.
As password is transmited in plain text it may not be secure, but what if I force HTTPS to authenticate?
Will it be safe?
As password is transmited in plain text it may not be secure, but what if I force HTTPS to authenticate?
Will it be safe?
Yes, and within normal limits, it is the only way to get it secured.
Just send the full password, but send it over a well secured TLS connection. You can use a secure key derivation function such as brypt or PBKDF2 and input the stored random salt (one per user) and password to retrieve the "hash", which can then be checked to the one stored in the database.
Note that you don't need to send a time stamp from the client. It is of course a good idea to log & limit the number of authentication attempts though. You cannot use a time stamp as input to a hash, the outcome would be different each time the time stamp changes.
I use the KeyChain to store user's username and password. But I want to store my application's username and password to access my web service. How can I store this securely?
There is no such thing as "some sort of key that only allows your app to access your web service." This is not a solvable problem. It is always going to be possible for clients other than yours (or modified versions of yours) to connect to your web service if used by an authorized user. You must account for this on the server side.
If your point is that you want to provide some thin layer of obfuscation to prevent trivial access to your service, then you would put the credential in your code. You definitely don't want to put it in Keychain, since that is per-device, and you want per-application. I would recommend a long, random string of bytes.
I’m developing a website of a client and they are sending out newsletters to their customers (through the website administration interface)
The newsletters are personal to each of the subscribed recipients/customers.
Each recipient/ customer is also a user with a username/password that enables them to sign in on the website and manage their newsletter subscriptions and participate in the sites community.
This all works like a charm.
Now my client want a “Manage my subscriptions” link in the newsletter email that when pressed automatically signs the recipient/customer in on the website with no need to remember username and password.
This could be easily solved be making a link like this:
http://mysite.com/manage.aspx?user=peter&password=hounddog
Of course information should not be clear text but encrypted in some way.
This however poses a problem since the only way a user can be authenticated on the website if by providing a valid username and password.
In the name of security, passwords are stored as hashed values in the database making it impossible for me to insert the password in the link.
What is the best way to accomplish this without compromising the security?
You will have to compromise your security somewhat, if you want people to be able to login without entering password. Note that even if you had access to the password (as in your example), you would have to embed it in a mail massage which would be transmitted in plaintext.
You can create a Guid associated with each user and message, and append it to the URL, and allow that to login automatically.
You could perhaps isolate the permissions so that a login through a newsletter guid link only allows the user to manage subscriptions, but that a real password-login is still required to participate in the forum. In that case its pretty limited what havoc can be wrecked if someone gets access to a Guid from a mail message.
Could you not insert an encrypted user name bundled with the hash value of the password?
What I mean is, encrypt & encode the user name to always be a particular length or to have a known break character in it then append the passwords hash value. this way, you could break apart the query string easily while still having the user name and password securely encoded. A straight compare of the hash values would be enough, with the unencrypted, decoded user name to allow access.
What about using an encrypted cookie that contains an access token ?
This cookie would be delivered after a successfull authentication by a separate page.
This kind of token can also be part of the URL query string.
Also you might consider using secured https instead of http.