I'm going to rephrase a question I asked earlier, as I don't think anyone understood what I meant.

Bascially I'm writting a web based password locker, which can have multiple accounts; so that users can share passwords (useful if you're in a website company and need to share login details to say "1&1" or "Fasthosts" etc...).

I've been doing tons of research into encryption algorithms, CSPRNGs, hashing algorithms, key stretching etc...

I dont want to implement my own encryption or hashing algoritms (because thats a big no-no!) instead, I want to use existing algoritms and apply them in a way that I've understood from my research.

I'm not a cryptogropher, so I may have understood something incorrectly, or something I've read about has actually been found to be insecure or its an old way of doing things and something better has come along. So I'd like to discuss what the thoughts are about implementing:

Hashing for storing the passwords of user accounts. and;

Encryption for storing the login details of websites that users can share.

Hashing

So, first of all, I need to store hashes of account passwords (these are the accounts that log into the application to view the shared passwords).

After reading around, my understanding is that to make a hash "more secure", you need to use scrypt or bcrypt or pbkdv2. I've found an implentation of these 3 alrogithms in "CryptSharp" (hopefully this is a secure implementation of these algorthms) - also after further research (http://www.tarsnap.com/scrypt/scrypt.pdf) it looks like sCrypt is a more secure way of creating a hash.

Is scrypt a secure way to create a hash of a user's password or should I use one of the other two (i.e. maybe sCrypt hasnt been tried an tested as much as the other two)? How can I tell if the implementation of sCrypt in "CryptSharp" is a good secure implementation?

Encryption

As the data will be shared between users, I shall need to make sure that the system uses a master encryption key for the entire project, and that this is stored securely.

My thinking here is generate an encryption key and initialization vector (3 of them - I'll explain why) - these will be generated with RNGCryptoServiceProvider, and all 3 will be concatenated into Key1|IV1|Key2|IV2|Key3|IV3 so that they can be split and used with the encryption algorithms.

I need some way of storing this concatenated string of IVs and Keys, so after some research I came across Microsoft's Data Protection API (ProtectedMemory.Protect( secret, MemoryProtectionScope.SameLogon )) - my understanding with this, is that the App Pool will need to run under a user account, and "load profile" set to true. The resulting encrypted string will then be stored in an XML setting file.

With regards to encrypting the passwords to be shared, I read about "cascading encryption" (used in TrueCrypt). The encryption algorithms TrueCrypt uses are; AES, TwoFish, and Serpent. I've found an implementation of these (http://www.bouncycastle.org/csharp/ - which again, I hope is a secure implementation). This is where the 3 IVs and Keys will be used; so effectively the data will be encrypted like so: Serpent(TwoFish(AES(data,key1),key2),key3).

So just to be clear on this; this is the process flow of encryption within the system:

  1. Upon installation of the system, the system will use RNGCryptoServiceProvider to create 3 encryption keys and 3 IVs.
  2. These 3 keys and IVs will be concatinated into a single string: Key1|IV1|Key2|IV2|Key3|IV3 (so I can split them and use them in the 3 encryption algoritms).
  3. This string will then be encrypted using Data Protection API and stored in a settings file.

  4. All shared login detailsare encrypted using "cascading encryption" of: Serpent(TwoFish(AES(data,key1),key2),key3) - the 3 keys and IVs will be decrypted on-the-fly, instead of being stored in memory.

When it's time to decrypt the shared login details:

  1. The 3 keys and decrypted using DPAPI
  2. Encryption is reversed: AES(TwoFish(Serpent(data,key3),key2),key1);

Is "cascading encryption" still a good idea? Is Data Protection API a good way to encrypt the keys and IVs?

So like I say, I know how to build the entire system and impelement my understanding of hashing and encryption above into the system... but is what I've discussed the right way of doing things? Am I over looking something? Did I misunderstand something? Am I using an old hat way of doing things?

I'd appreciate any advice. Many thanks.

  • 1
    Your new question isn't really better than the old one (just longer), and I think the misunderstanding is on your part. I didn't say that you're trying to invent your own algorithm. I said that you're trying to come up with your own protocol, which is just as bad. The mere fact that you ask us whether this is valid means that you've left the realms of established solutions and entered the do-it-yourself area. The only advice I can give you is: Don't do it. I realize that you don't like this answer, but anything else would simply be unprofessional. – Fleche Jul 4 '14 at 12:17
  • I completely agree - the misunderstanding is on my part, which is why I tried to rephrase my question to hopefully expand on what I was trying to acheive. Also, your comment is actually helpful - I hadn't thought about that fact that I'm writting my own protocol, and that implementing my own protocol is as bad as implementing my own algoritm, so thanks making me aware of that. – binks Jul 4 '14 at 12:31
  • I'll disagree slightly with Fleche and say actually, what you have isn't all that bad right up until you attempt to deploy encryption. Using bcrypt/scrypt is fine for hashing and storing the passwords. – AlexH Jul 4 '14 at 14:43
up vote -1 down vote accepted

This post might be downvote but I find your real question interesting. Which I consider to be:

How to share password between user of your service on Internet?

Let's start with some assumptions

Architecture of your service

  • Each user have an account protected by a master password known only by themselves
  • Each user have a series of encrypted password associated with their account
  • The master password need to be hashed before storing it in the database.

Now we need to be able to securely share these encrypted password.

There is a website that do something similar : LastPass.

One thing to note about LastPass is that all their encryption is done on the client side. LastPass use your master password, the password you use to log into your account, to encrypt all your other password on the client side, your own machine.

This has the advantage that your master password never leave your own machine and hence, unless your computer is compromised by a virus, it's impossible for anyone else than you to decrypt your other passwords. Not even LastPass administrators. So your passwords are in the cloud but it's like if they were in your own head.

LastPass is also able to share password between users. I don't know how they do that but I will take a random guess...

Using public/private key

Asymetric encryption is the key here. You can easily add a public key and a private key to the account. The public key need to be in plain text so other are able to use it. But, the private key need to be encrypted with your master password on the client side, like all your other passwords, before being stored on the server.

Now, if someone want to share a password with you, he just need to request your public key using your account name (or another alias), then he encrypt one of his password with your public key and send it to the website that will add it to your account.

When you log in, you will see that you have received a new password. You can then decrypt it on the client side using your private key, reencrypt it using your master key and store it back on the server.

  • 1
    From a high-level perspective, it always sounds trivial. Describing HTTPS in your style would look like this: “If you want to exchange data with a server in a secure way, you just request their public key and send them the encrypted data. Easy.” Well, we all know it's not easy at all. One of the problems with public-key cryptography is making sure that you indeed got the right public key. You can't just trust the server. And good luck implementing this correctly. I know that beginners like to challenge the “Don't roll your own” mantra. But there's a reason why almost everybody agrees on it. – Fleche Jul 4 '14 at 13:54
  • @Fleche Here, you got a big advantage over implementing your HTTPS : you are already logged in to the server that store all your password which provide you a secure connection to transmit data and you can already trust the identity of that server. When that server gives you a public key, you can be sure it's the public key of the user you requested. If you requested the wrong user then it's your problem. – Gudradain Jul 4 '14 at 13:58
  • @Gudradain you assume TOTAL security of the server, which is a factor of trust - it turns out you can use special whitespace characters in a username, it might appear identical to another user - thats only one example, but only any one thing needs to go wrong for the whole system to collapse, this applies more with password storage than virtually anything else (probably, no evidence/source just a very hungry gut) – user2867314 Jul 4 '14 at 15:35
  • @user2867314 I assume TOTAL security of the server because that server is already storing all your passwords for nearly all the websites that you visit. If the server is not secure, you are in much bigger trouble than sending 1 password to the wrong person. Also, as I said before, if you decide to send your password to the wrong person then there is nothing anyone can do to stop you. You are the one typing the username so you are the only one to blame for a mistake. – Gudradain Jul 4 '14 at 17:18
  • None of this makes a lot of sense. You started off by stressing that services like LastPass do not have access to the passwords, because all encryption happens client-side. That means you do not have to trust the server. Now you're suddenly switchting positions and describe the exact opposite: The server stores all passwords, and you need to blindly trust it. I don't even see how public-key cryptography fits into your new model. This isn't getting anywhere, and it's a great example why homegrown cryptography is harmful. – Fleche Jul 4 '14 at 18:17

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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