I have asked many people about this question but they said, integrity must be conserved for the privacy of any communication system. Is it correct that integrity violation violate the privacy too?
Integrity is generally accepted as a basic security property, and maintaining security properties is important for protecting privacy, even if integrity itself is not typically considered a privacy property.
Integrity is a pre-requisite for being able to trust the communications that a user receives. If an attacker can modify the messages that I believe are coming from a trusted correspondent, then I might reveal information based on that message (the attacker could redirect me to a fake URL, or impersonate my friend and convince me to inadvertently reveal something confidential to the attacker). That is, integrity is a necessary building block for authentication, on which we have built many privacy assurances.
I would say integrity is also privacy-relevant in other ways. Privacy involves communicating choices in my communications, and if I don't have integrity of communications, I can't be sure that my preferences are expressed to the other party. And privacy can also include protection from intrusion -- without integrity, an attacker can modify the messages a user receives to include abuse.
Related
A third-party application states that TDE is used for encrypting the password database.
I don't know how appropriate this is for password storage as surely a decryption key still exists despite the fact that it is itself encrypted. The third-party state that internal staff do not have access to the passwords but I'm struggling to understand how that can be true as my understanding of encryption would not agree.
I've spent some time googling and whilst i understand the concept of TDE at a high-level, I am not convinced it's appropriate for storing customer passwords and claiming that no internal staff member can access these passwords.
Any comment or clarification would be much appreciated!
During a Diffie Hellman keyExchange, if a man in the middle is able to get the values of the prime "p" and the generator "g". Can he now decipher the private keys or the shared secret secret generated ?
No, these are the public components of the key exchange protocol, and can be observed by an eavesdropper without compromising the security of the agreed key (assuming they have been chosen properly), as it requires the eavesdropper to solve the Diffie Hellman problem, which is considered difficult. This is described in more detail in the Wikipedia entry on Diffie Hellman.
It's worth noting however that the protocol as described there, whilst safe from eavesdropping does not in itself authenticate the parties involved, and so it is vulnerable to a man-in-the-middle attack if implemented without additional authentication.
I understand that it is possible to hijack the asp.net session by stealing the asp.net session cookie. I guess that I'm thinking of stealing the cookie as it is transmitted over unsecure wi-fi.
Other than using SSL are there standard ways of securing this information? Or preventing the hijacking of the session?
Sadly, the only way to prevent cookies from being used in a replay attack is to send them over HTTPS since that ensures that the cookie itself is encrypted and, therefore, kept from prying eyes.
Have you seen Jeff Atwood's blog entry about this matter, Breaking the Web's Cookie Jar? Jeff focuses more on the concerns from the user's perspective, but it's worth reading anyway. Here's what he says folks can do today:
So here's what you can do to protect yourself, right now, today:
We should be very careful how we browse on unencrypted wireless networks.
Get in the habit of accessing your web mail through HTTPS.
Lobby the websites you use to offer HTTPS browsing.
This is very broad advice, and there are a whole host of technical caveats to the above. But it's a starting point toward evangelizing the risks and responsible use of open wireless networks.
There probably needs to be some sort of new, more secure approach for cookies going forward, but who knows if there will be enough traction to warrant such change or enough interest to spurn adoption. For web applications where security is paramount - think medical information websites, financial websites, and so on - the only plausible option is to require HTTS for the user's entire browsing session.
There is no easy solution to that problem, other than requiring the authentication information with every page request (which isn't practical and is worse from a security standpoint in an unencrypted environment).
In order to maintain state while using HTTP (which is stateless), something like a cookie must be used. If that cookie is being sent unencrypted, it can be used by somebody else.
As a side note, if you have to pick between two evils of having a session hijacked and having the password compromised, you would rather have the session hijacked. That is why it is crucial that changes like password modifications require re-authentication so that a hijacked session can't take over the account itself. Of course that can also be circumvented if the authentication credentials are not encrypted.
I am storing OpenIDs into a database so I can log in users very quickly. Should I be encrypting them in my database?
An alternative question would be, are they considered 'sensitive' information?
Contrary to another answer: No. There's no point in doing it.
To get access to an account, one must first authenticate with the OP. There is no method to somehow break into someone's account by simply knowing an identifier (and only that).
The OpenID protocol, by design, allows users to place their identifiers in very obvious places (like their homepage) with little additional risk. If identifiers were meant to be 'sensitive' information, it wouldn't be possible to delegate OpenIDs.
If the fact that your database has been compromised would imply that an attacker has access to all the identities, OpenID would be really, really insecure (and it isn't).
The OpenID identifier is only a url pointing at a provider. From this information, you can't infer anything more than who the user claims to be (and in case of directed identity, not even that).
You could ask yourself: "Should I be encrypting logins?"
If your answer is true -- encrypt the identifiers, because they are no different.
If it's false, then don't bother.
Asp.net stores the session in a cookie, thus not having to worry about sessions on the server side (traditionally sessions are stored in a database, and lookups are done via a session ID, which is usually a Guid like string).
In my previous question, I was asking about how a spring application stores/creates sessions etc: Spring authentication, does it use encrypted cookies?
Cletus pointed out that storing a username/id in a cookie, although encrypted, is a security issue because the would-be-hacker has both the encrypted text, but also the hacker knows what the actual encrypted text is i.e. the userId or username.
What are you thoughts on this?
I am sure StackOverflow is also using this mechanism, as is **99.9% of asp.net web applications that are using formsauthentication in this manner.
Microsoft's MSDN site itself is filled with examples like:
FormsAuthentication.RedirectFromLoginPage(UsernameTextbox.Text, NotPublicCheckBox.Checked);
In the above code, the username value is stored in the encrypted cookie.
actually, I recall that the asp.net website was hacked because the web.config didn't have the Protection=All in the forms authentication tag.
So is this a real issue?
To repeat what cletus linked to:
In case you're wondering what a "crib" is. see: http://www.faqs.org/faqs/cryptography-faq/part03/
Cryptanalytic methods include what is
known as practical cryptanalysis'':
the enemy doesn't have to just stare
at your ciphertext until he figures
out the plaintext. For instance, he
might assumecribs''---stretches of
probable plaintext. If the crib is
correct then he might be able to
deduce the key and then decipher the
rest of the message. Or he might
exploit ``isologs''---the same
plaintext enciphered in several
cryptosystems or several keys. Thus he
might obtain solutions even when
cryptanalytic theory says he doesn't
have a chance.**
Maybe you should take a look into this document: Improving Web Application Security: Threats and Countermeasures -- Threat Modeling
It's a good start point to understand what security risks are involved and how can you mitigate that threats.