Security question: authentication vs authorization ?

Question

Let's assume I must have user's sensitive data that was optionally encoded on the client side.
Encryption (optional) should be done with user's passphrase.
User login (optional) should be done with user's password.

Notes:
plain-text password is not stored on the server or transfered over the network.

My options and their drawbacks:

1. No authentication, Client-side authorization:
Server gives the data to everyone, but only the original user have the means to decode.
Data can be used by anyone to try to crack the encryption - not the best way to secure it.

2. Server-side authentication, no authorization:
Server stores user's password to access the data, and only gives the data to the user that can provide the right password.
Users don't trust the network for transferring their data without encryption.

3. Authentication and authorization:
Server stores user's password to access the encrypted data, the encryption is done using passphrase that is different from user's password.
Good security, but users don't want to remember two passwords.

4. Authentication vs authorization: Server stores user's password to access the encrypted data, the encryption is done using the same password.
Users are happy. Some security concerns.

I prefer the latest fourth option, but my concern is:
What if the server will get compromised, how can I be sure that encrypted password and encrypted data can't be used together to break the encryption? How can I make it more harder to break the encryption?

Some thoughts:

• Use different encryption algorithms for password and data.
• Add fixed string to the end of the user's password before encryption.
• Pad user's password to some length.

---

EDIT:

The system should be very similar to a backup system that should be secure from all sides: server should not be able to read the data, only the original client should be able to access the data and man in the middle attacks should be prevented. So if someone hacks the server authentication or the client encryption the data should not be revealed.

It should be web based, so man in the middle attack should be prevented with HTTPS.

To prevent server hacks revealing the data, the data is encrypted in client-side.

To prevent client encryption tampering, the access to the data should be protected on the server side with some kind of a login and/or password or a token (may be unique URL).

Answer 1

Use option one and make the URL for the data contain a long random string. Anybody who knows the random string can get the data. Of course, only the client who created the data is going to have that URL right off.

If someone wants to give someone else revokable access, allow them to generate a new random URL and provide a means for them to name that random URL and revoke its ability to get at the data.

Capability based security is easier to get right, more flexible and makes more sense to users. There is a really excellent YouTube video about capability based security and a nice website with some essays about it.

Answer 2

@Vitaly, permit me to clarify some terms before I answer, as you seem to be using a different meaning for some than is commonly used.

Authentication - the process of proving who you are (more accurately, that you own the identity you are claiming).
Authorization - the mechanism used to restrict, control, and grant access.
Encryption - a mechanism for protecting data, even from someone who has access to it.

Now, allow me to rephrase your options, and then I'll suggest something else:

1. No Authentication, No Authorization, Client-side encryption
2. Server-side authentication, Server-side authorization, Server-side encryption
3. Server-side authentication, Server-side authorization, Client-side encryption
4. Server-side authentication, Server-side authorization, Client-side encryption using server credentials.

Now, I think it can be clearer where each one stands.
In general, you really want to follow the "best practice" (dont get me started on those) principle of "Defense in depth", i.e. dont use only encryption, or only access control, instead use both! But, as you pointed out, this can be in contrast (if the user is required to remember TWO passwords) to another principle, "Keep Security Simple".

Without trying to be TOO annoying, you didn't give much information in the way of your environment. For example, is this e.g. a Web application? If so, why is SSL/TLS not enough encryption for you? Or is this a question of users uploading personal data that you (and your system) should not see either (e.g. a backup-type service)? In which case client-side encryption would be necessary...

So, (finally) my proposed options, depending on your environment / requirements:

1. If you can, rely on secure protocols (e.g. SSL/TLS) for encryption. Use server-side authentication + authorization, protocol encryption.
2. If your system needs to further protect this data, e.g. credit cards (note that I am not currently a PCI:QSA ;) ), use the previous option, and in addition server-side encryption using a server-generated encryption key (NOT the password) (and of course protect that).
3. If the data needs to be protected FROM your system, you will need to do client-side encryption IN ADDITION to server-side authentication+authorization (your option 3 as I restated it).
   However, you don't necessarily need to force the user to remember an additional password/phrase. Again, depending on your environment, you might be able to consider some form of key stored on the client, e.g. a certificate in the user's certificate store / keyring, or even stored in a protected configuration file; a key based on biometric data (not easy but i've seen this done successfully, though it has its own set of issues), out of band key distribution (e.g. via cellphone), etc. This would enable you both to use strong keys, prevent the server from accessing those keys, not require the user to remember two keys, and doesn't re-use a single password for different usages in different contexts.

Answer 3

@Vitaly

Probably best to clarify some terms first. Then I will give you what I think to be the best move in your situation.

First, as @AviD mentioned, it is probably best to clarify what you mean by Authentication and Authorization. The two are distinct terms and play very different roles when it comes to securing applications. Taken from this blog post on Authentication vs Authorization:

Authentication is the process of verifying that a user has the right to access an application.

Authorization determines what actions a user has the right to take within an application.

That said, let's turn to the question of data security. Use the HTTPS protocol to secure network traffic between your server and the user's client. In addition, think about hosting your data, business logic and user interface on completely separate servers (multi-tier). Or at the very least, don't expose your application to a web accessible directory.

You didn't give much detail to the nature of the data you're trying to secure, but let's assume you're talking about credit card data. Consider storing that data on a separate server on your LAN that is not connected to the "outside world." Then use a token-key system to both link and dissociate the credit card data from your main data repository. Then your application would only have access to meaningless tokens, instead of the actual sensitive data.

Finally, I would strongly advise against using an un-authenticated unique url as a means for the user to access sensitive data. Even if the url is random, if someone or a bot can just guess at the URL, what's the point of even discussing security?