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 need to implement a sensitive data protection scheme which can meet the requirements on secure data transmission, protection and storage, assuming mutually trusted third party is not available, that is, we cannot use SSL, TLS etc. But this doesn't means I will implement SSL by myself, I still would like to outsource encryption and decryption parts to existing codes.

I have drafted below scheme as my account and password protection solution:

Assumptions on our attackers:

have complete knowledge of the protocol.

have access to a large dictionary of commonly used passwords.

can eavesdrop on all communications between client and server.

can intercept, modify, and forge arbitrary messages between client and server.

can access the source codes (including encryption code) on the client-side.

Solutions:

1, RSA (encryption & decryption on client and server sites respectively, public key is safe for transmission, there are not risk if the key is obtained by a hacker.)

2, SHA256/SHA512/Twice MD5 (Encryption with User ID binding Salt, both stored in database on the server site. I use binding salt here to avoid common password and prevent rainbow table.)

Registering a New User:

  1. First Generate RSA keys on server end ( Stored in session);
  2. Send public key to client;
  3. Store public keys in javascript variable;
  4. In All subsequent requests use this key to encrypt data and send to server;
  5. Use private keys stored in session to decrypt user account and password on server side;
  6. Encrypt the passwords with one-way encryption algorithm with a random salt (like the common opinion: SHA-256 is stronger than MD5);
  7. Store the user id , the hash password and the random salt (user id binding) into database (avoid common password and building specific rainbow table).

Existing User Login:

  1. First Generate RSA keys on server end (stored in session);
  2. Send public key to client;
  3. Store public keys in javascript variable;
  4. In All subsequent requests use this key to encrypt data and send to server;
  5. Use private keys stored in session to decrypt user account and password on server side
  6. Fetch the hash password and the salt from database by using the user account;
  7. Encrypt the passwords with one-way encryption algorithm with the obtained random salt;
  8. Compare the encrypted password with the hash password obtained from the database;
  9. Determine login success or failure.

I am new in this parts and i do need some professional suggestions from you? Is the scheme secure enough? Many thanks.

share|improve this question
2  
Man-in-the-middle attack, don't ever roll out your own crypto protocol. RSA, SHA, ... all such things are nothing if the protocol is broken. –  ordag Mar 3 '12 at 15:31
    
Step 5 confuses me. Whole thing likely vulnerable to MITM. If your goal is security-theater (as you tagged your question)... well it seems like you've achieved that. –  makerofthings7 Mar 3 '12 at 15:41
    
There isn't any single config that is 'secure enough'. You need to decide what secure enough means for you, and describe your requirements. Then we can help find an answer that meets those requirements. So I have closed this until you update your question with this information. –  Rory Alsop Mar 3 '12 at 15:45
    
Hi Damao17, welcome to Information Security. Please take a look at the FAQ, and also read How to Ask. As @RoryAlsop said, you should add some context and background to the question. That said, lacking a trusted 3rd party does not mean you cannot use SSL - it just means you cant use certs issued by a 3rd party. I.e. you can use self-signed certs (and just deal with cert publishing), or better yet issue them from your own CA (if the client can trust the CA's cert). Never create your own protocol! You WILL get it wrong! –  AviD Mar 9 '12 at 0:19
add comment

closed as not constructive by Rory Alsop Mar 3 '12 at 15:46

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.