Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I'm working on a Mac app. I have users stored using DynamoDB. Authentication is needed to enforce access control on system-internal operations, such as uploading files to Amazon S3. Of course, I would want a secure authentication mechanism.

I thought about one-way hashes. The hashed password would be stored in DynamoDB. For authentication, I'd make a request, then hash the password the user entered and compare the stored and the transferred hash. With a network-sniffer, an adversary would be able to see the hashed password.

Like I said, authentication is only needed internally, so there is no other way to get the credentials than though the app.

Could there be security issues with this approach? Also, which hash function do you recommend?

share|improve this question
add comment

1 Answer

up vote 3 down vote accepted

Edit: This is not relevant to this particular question, but an advice on the subject in general.

It sounds like what you really want is a proper authentication mechanism. You should not try to roll your own, as it is considered bad practice. One secure and reliable authentication mechanism is HTTP Digest Access Authentication, which is deeply anchored in the HTTP framework. It is a challenge response protocol, meaning that something along these lines happen, when a user tries navigating to the "upload files" mechanism:

  1. User navigates to http://example.org/protected/upload.html
  2. Server notices that the /protected/ directory or the upload.html file is protected by Digest Authentication and responds with a 401 Authorization required error code. In it is a challenge for the user agent (the web browser) to respond to. The answer is calculated using the challenge, the user's credentials (username and password) along with some other information.
  3. User enters password, leading to the user agent providing the server with an Authorization header, containing the response to the challenge

  4. The server, using the credentials he has stored on the user, calculates the same response value using the same data that he sent the user.

  5. The server compares the received and the locally generated response value, and if they are equal, grant access to the protected realm

All this is done using MD5 hashing as a standard. The application and servers can be configured to use MD5, SHA-X or any hashing algorithm - even iterated hashing, as long as the same procedure is followed on each side of the communication.

MD5 is considered broken, in the sense that it is fairly easy to find collisions. This is not a problem for this authentication process, as it requires a form of a preimage attack to successfully collect the password. This is only possible theoretically with a computational complexity of 2123.4.

If you are intimidated by this, or the scheme does not fit what you really need, at least store your password in a salted, hashed way, i.e. the database contains:

username | hash_function(password+":"+salt) | salt

Here, SHA-256 should be alright.

Please ask for more details on HTTP Digest Auth. if interested. Also, consider adding your type of server application (Apache?) to the question.

share|improve this answer
1  
Thanks a lot for your answer! The problem is that I'm not using any server. DynamoDB is an Amazon Web Service. I connect to it using the provided api. I currently have no server between application and db, because of independence and speed. I have read that you should consider SHA-3. It's easier to implement it right than migrating it in a year. –  NSAddict Oct 19 '12 at 16:40
    
Right - I guess my answer is quite superfluous :D. At least, I have a comment about SHA-3: The reason you've been told to consider SHA-3 is probably only hype, as it was elected about two weeks ago. It has gone through a generous amount of scrutiny in the election process, but it is not as mature a hash function as SHA-256, meaning that the **extremely improbable ** event that a serious vulnerability is discovered still is a little more probable than an older one, which is still endorsed by the industry. Just remember to salt! –  Henning Klevjer Oct 19 '12 at 16:51
    
Great, thanks!! –  NSAddict Oct 19 '12 at 17:11
1  
I would vote +1 if I had the reputation :D –  NSAddict Oct 19 '12 at 17:11
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.