Encrypting files using an existing encrypted password and password salt?

[zachattack05]

The Membership table for our ASP.NET site has the encrypted passwords and password salts stored when a user logs in.

The site is already served over an HTTPS connection, but we would like to give our clients the ability to download and save certain files and documents. We would like to have those documents encrypted (essentially password protected), which we can do, but, we would like to have them be able to open those enrypted documents using the password they use to login to the site.

Is it possible to do this?

Essentially, I don't see how it would be difficult. We don't want to know the user's password, all we want is to essentially "wrap" the contents of a file in a shell (zip file or whatever) and when they open the file, the password they provide is checked against the embedded password and salt values and if they match, open, if not, don't. I'm just not sure if it's possible when encrypting a file, or password protecting it, to be able to say, essentially, "OK, password protect this file, here's the password that's already encrypted using XYZ algorythm. Don't encrypt it again, it already is."

Does this make sense?

[pritaeas]

Can you not zip the files using the password? Zip has built-in support for encrypting it's contents.

You'd need the original password though. If you cannot decrypt them, I doubt it's possible.

[zachattack05]

I could, but I don't know what the passwords are.

They are stored in a one way hash.

[rproffitt]

I don't want to sound as if I'm dissing on your concept but this is a bad idea. Putting the password as the zip's password weakens your password's security.

How? There are a number of ZIP file password crackers so by using this password like that, you've degraded that password.

Why not make it a password for the site? Save yourself before you create a monster.

[pritaeas]

Another option is to generate a password, and email it to the receiver after he downloads the file successfully.

[rubberman]

Assuming you store the salted password in the database, why not use that to zip the files? If the user wants to access that data, then since they have been authenticated by the login process, you can just use that salted hash to unzip the file and give them access to download, view, or whatever.

[zachattack05]

Sorry for the late reply!

rproffitt, I don't see how it degrades the password. There are many zip cracking tools out there, true, but there are also many tools to brute force their way into http login forms as well. Passwords come with risks in general. Since the files are served over a HTTPS connection and are provided to those who download them, no one else should be able to access them and attempt to crack the zip password unless they have physical access to the downloader's machine. This isn't something I can protect against, regardless of the password.

pritaeas, I've toyed with the idea of doing that, but the drawback is that the user has to wait for the email to arrive and if it doesn't for whatever reason, then it can cause issues. I was hoping to have it be simple in that the user can just use the password they already know to open the files. The other disadvantage is that the password then could reside on email servers that could be used later to re-open the file.

I might just let them download it without a password and just keep the file unprotected. After all the connection is encrypted as well as the fact that the user has to login to download it to begin with. Once it's on their machine, security is out of my hands anyway.

[rproffitt]

I have to keep it short. The current password of a GREAT web site is not stored. Only the result of a (ready?) "One Way Encryption" is stored. So while you could run a brute force attack the web site didn't tell you the encrypted result, until you revealed the password by the method you are writing about.

You also compromised the great web site as now you must use their password to zip it.

I think you need to meet with your security chief and hash this out until you see the problems you are introducing.

-> as to access to their PC, in the news are more and more ransomware. If you do what you wrote, then you are adding to the problem. Again, this may take a lot of time with your security chief or team till you see what you've done.