Simple encyption/keys question - please pelase help :)
-
Hey. I am building an application where there will be different 'users', each with a username and password. The application is using a webservice (Amazon S3) which requires a logon also. It is envisaged that a company buys an S3 account, and allows it's users to utilise it through an application. The users can store and delete files on their part of S3. Each user would only have access to their own files, etc. Deciding who's files belongs to who is a different issue. Anyway, so if, say, Joe logs into the application, his password is checked against a database on a central sever, and upon authentication, the S3 'access ID' and 'secret access ID' is sent to the application, which then uses it to log on S3. The users password would initially be MD5'd, and then sent to the server for authentication. (The database will hold MD5'd passwords). So my first question is: What's the best way to get the 'access ID' and 'secret access ID' from a central server, to the user? Obviously, to keep it secret it would need to be encrypted. The application can be ran on any machine, so a key cannot be stored, say, in the registry. I was considering encrypting the S3 access/secret id string with an MD5 of the users password, but that'll be sent over the network too, and itself will be exposed. Please, any ideas greatly appreciated??? Next, then Joe wants to upload files. I am looking for any suggestions on how to encrypt these files, using a different key for each user. So, for example, a company admin couldnt go onto the S3 service, and look at a users files, without knowing the encryption/decryption key. Again, I was considering using an MD5 of the users password as an encryption/decryption string, but this itself poses the problem whereby a user changes password. My main problem is how to get a string from the server to any PC, but for it not to be exposed on the network. Any help in this whole area is much much much appreciated. Regards, Cormac Redmond
-
Hey. I am building an application where there will be different 'users', each with a username and password. The application is using a webservice (Amazon S3) which requires a logon also. It is envisaged that a company buys an S3 account, and allows it's users to utilise it through an application. The users can store and delete files on their part of S3. Each user would only have access to their own files, etc. Deciding who's files belongs to who is a different issue. Anyway, so if, say, Joe logs into the application, his password is checked against a database on a central sever, and upon authentication, the S3 'access ID' and 'secret access ID' is sent to the application, which then uses it to log on S3. The users password would initially be MD5'd, and then sent to the server for authentication. (The database will hold MD5'd passwords). So my first question is: What's the best way to get the 'access ID' and 'secret access ID' from a central server, to the user? Obviously, to keep it secret it would need to be encrypted. The application can be ran on any machine, so a key cannot be stored, say, in the registry. I was considering encrypting the S3 access/secret id string with an MD5 of the users password, but that'll be sent over the network too, and itself will be exposed. Please, any ideas greatly appreciated??? Next, then Joe wants to upload files. I am looking for any suggestions on how to encrypt these files, using a different key for each user. So, for example, a company admin couldnt go onto the S3 service, and look at a users files, without knowing the encryption/decryption key. Again, I was considering using an MD5 of the users password as an encryption/decryption string, but this itself poses the problem whereby a user changes password. My main problem is how to get a string from the server to any PC, but for it not to be exposed on the network. Any help in this whole area is much much much appreciated. Regards, Cormac Redmond
Cormac M Redmond wrote:
The users password would initially be MD5'd, and then sent to the server for authentication. (The database will hold MD5'd passwords).
MD5 is broken. Consider using SHA256 of SHA512. Also you might want to consider using a salted hash. This means adding some additional random data on the front of a password before it is hashed so that in the event that two users happen to have the same password it isn't obvious by looking at the resulting hash values. The salt is stored in plain text in an additional column in the database. The salt being in plain text has no value to an attacker because its function is solely to remove the ability to detect duplicate passwords. A brute force attack would still be necessary to break the password. When a user types their password the salt is added to the password as before, then it is hashed and the salted hash values are checked.
Cormac M Redmond wrote:
So my first question is: What's the best way to get the 'access ID' and 'secret access ID' from a central server, to the user? Obviously, to keep it secret it would need to be encrypted. The application can be ran on any machine, so a key cannot be stored, say, in the registry. I was considering encrypting the S3 access/secret id string with an MD5 of the users password, but that'll be sent over the network too, and itself will be exposed. Please, any ideas greatly appreciated???
Consider the use of public/private key encryption. The basic idea is that anything encrypted using the public key can only be read by the holder of the private key. Anything encrypted with the private key can be read by anyone with the public key. The former could be useful for your purposes, the latter is useful when you want to authenticate where something has originated. So, you decide on an asymetric encryption algorithm, you send the issuer of the access/secret id your public key. When the data comes back, you are the only one that can read it because you have the private key. It doesn't matter than anyone can see the public key because it is no use to them.
Cormac M Redmond wrote:
I was considering using an MD5 of the users password as an encryption/decryption string, but this itself poses the problem whereby a user changes password.
You also have the problem that you are using a key that can be discovered. If you are using a hashed vers
-
Cormac M Redmond wrote:
The users password would initially be MD5'd, and then sent to the server for authentication. (The database will hold MD5'd passwords).
MD5 is broken. Consider using SHA256 of SHA512. Also you might want to consider using a salted hash. This means adding some additional random data on the front of a password before it is hashed so that in the event that two users happen to have the same password it isn't obvious by looking at the resulting hash values. The salt is stored in plain text in an additional column in the database. The salt being in plain text has no value to an attacker because its function is solely to remove the ability to detect duplicate passwords. A brute force attack would still be necessary to break the password. When a user types their password the salt is added to the password as before, then it is hashed and the salted hash values are checked.
Cormac M Redmond wrote:
So my first question is: What's the best way to get the 'access ID' and 'secret access ID' from a central server, to the user? Obviously, to keep it secret it would need to be encrypted. The application can be ran on any machine, so a key cannot be stored, say, in the registry. I was considering encrypting the S3 access/secret id string with an MD5 of the users password, but that'll be sent over the network too, and itself will be exposed. Please, any ideas greatly appreciated???
Consider the use of public/private key encryption. The basic idea is that anything encrypted using the public key can only be read by the holder of the private key. Anything encrypted with the private key can be read by anyone with the public key. The former could be useful for your purposes, the latter is useful when you want to authenticate where something has originated. So, you decide on an asymetric encryption algorithm, you send the issuer of the access/secret id your public key. When the data comes back, you are the only one that can read it because you have the private key. It doesn't matter than anyone can see the public key because it is no use to them.
Cormac M Redmond wrote:
I was considering using an MD5 of the users password as an encryption/decryption string, but this itself poses the problem whereby a user changes password.
You also have the problem that you are using a key that can be discovered. If you are using a hashed vers
Thanks. That's all very helpful! I'm slightly confused regarding the salting. Is this how it should work? Say, I try to login to the application from any P.C.: Username: Cormac Password: Redmond Would the application tell the server to get the salt key from the table where, say, username = Cormac? And then send the salt key BACK to the application, which would then creat the salted hash value and send back to the server for authentication? *breath* Therefore, when creating the salts and populating the database, there would be checks that none of them are the same, thus there never being similar hash values? Also, could you recommend a suitable public/private key encrpytion algorithm? RSA...Diffie-Hellman? Thanks for the help. Regards, Cormac Redmond -- modified at 0:03 Monday 1st January, 2007
-
Thanks. That's all very helpful! I'm slightly confused regarding the salting. Is this how it should work? Say, I try to login to the application from any P.C.: Username: Cormac Password: Redmond Would the application tell the server to get the salt key from the table where, say, username = Cormac? And then send the salt key BACK to the application, which would then creat the salted hash value and send back to the server for authentication? *breath* Therefore, when creating the salts and populating the database, there would be checks that none of them are the same, thus there never being similar hash values? Also, could you recommend a suitable public/private key encrpytion algorithm? RSA...Diffie-Hellman? Thanks for the help. Regards, Cormac Redmond -- modified at 0:03 Monday 1st January, 2007
Cormac M Redmond wrote:
Therefore, when creating the salts and populating the database, there would be checks that none of them are the same, thus there never being similar hash values?
If you use a GUID as a salt value you are virtually guaranteed uniqueness. You'd have to generate billions-upon-billions of GUIDs before you'd get a collision - in fact the number is closer to 2.5 * 1038 (250 undecillion) - If you had all the PCs in the world cranking out GUIDs constantly it would still take a heck of a long time. You can also use something simpler. Like the primary key of the row in the database - since a primary key is guaranteed to be unique it could be a good candidate. Typically, I just use a random number generator to generate a random sequence of bytes.
Cormac M Redmond wrote:
Also, could you recommend a suitable public/private key encrpytion algorithm? RSA...Diffie-Hellman?
You may want to take a look at this entry on Wikipedia[^]. It will help you choose an algorithm that is suitable. From this point you make also find other useful information about cryptography. One thing to remember about public/private key cryptography is that they are computationally expensive when compared to symmetric encryption - so they are only ever used to encrypt small pieces of data, often they are used to encrypt symmetric keys.
Upcoming Scottish Developers events: * Glasgow: Tell us what you want to see in 2007 My: Website | Blog | Photos
-
Cormac M Redmond wrote:
Therefore, when creating the salts and populating the database, there would be checks that none of them are the same, thus there never being similar hash values?
If you use a GUID as a salt value you are virtually guaranteed uniqueness. You'd have to generate billions-upon-billions of GUIDs before you'd get a collision - in fact the number is closer to 2.5 * 1038 (250 undecillion) - If you had all the PCs in the world cranking out GUIDs constantly it would still take a heck of a long time. You can also use something simpler. Like the primary key of the row in the database - since a primary key is guaranteed to be unique it could be a good candidate. Typically, I just use a random number generator to generate a random sequence of bytes.
Cormac M Redmond wrote:
Also, could you recommend a suitable public/private key encrpytion algorithm? RSA...Diffie-Hellman?
You may want to take a look at this entry on Wikipedia[^]. It will help you choose an algorithm that is suitable. From this point you make also find other useful information about cryptography. One thing to remember about public/private key cryptography is that they are computationally expensive when compared to symmetric encryption - so they are only ever used to encrypt small pieces of data, often they are used to encrypt symmetric keys.
Upcoming Scottish Developers events: * Glasgow: Tell us what you want to see in 2007 My: Website | Blog | Photos
I wonder why good informative posts like this get only my vote of 5?!!Why don't CPains vote in favour of a post anymore -only voting ones and twoes-? Thanks Colin. Even though I didn't ask the question, but I've been really pleased by reading your well said, well organized post.
Regards:rose:
-
I wonder why good informative posts like this get only my vote of 5?!!Why don't CPains vote in favour of a post anymore -only voting ones and twoes-? Thanks Colin. Even though I didn't ask the question, but I've been really pleased by reading your well said, well organized post.
Regards:rose:
I didn't even know you could vote, if you're reffering to me! :)
-
I didn't even know you could vote, if you're reffering to me! :)
Oops!:-> I didn't even imply it.. I just noticed this for some weeks that many good posts don't get high votes anymore -excpet mine if I were around-, and I was a bit frustrated. Forgive me if you got offended. I really didn't mean you Personally.
Regards:rose:
-
Oops!:-> I didn't even imply it.. I just noticed this for some weeks that many good posts don't get high votes anymore -excpet mine if I were around-, and I was a bit frustrated. Forgive me if you got offended. I really didn't mean you Personally.
Regards:rose:
Hehe. I wasn't offended. Anyway, at least now I know! ;)
-
I wonder why good informative posts like this get only my vote of 5?!!Why don't CPains vote in favour of a post anymore -only voting ones and twoes-? Thanks Colin. Even though I didn't ask the question, but I've been really pleased by reading your well said, well organized post.
Regards:rose:
Nader Elshehabi wrote:
Thanks Colin. Even though I didn't ask the question, but I've been really pleased by reading your well said, well organized post.
Thank you. I very much appreciate your compliment. :rose:
Upcoming Scottish Developers events: * Glasgow: Tell us what you want to see in 2007 My: Website | Blog | Photos