This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

User talk:Mohammed ALDOUB

From OWASP
Revision as of 22:19, 7 August 2012 by Mohammed ALDOUB (talk | contribs)

Jump to: navigation, search

User Legal and Political Protection Cheat Sheet

Introduction

The political and legal impact of online activities has been rising significantly over the years, with users now able to take down entire governments and change legislation using online services and social networking. This fact puts into focus the grave danger users are getting introduced to by using these online services, especially in oppressive regions around the world.

This OWASP Cheat Sheet introduces risks and mitigations that web developers need to realize in order to protect their users from a vast array of potential aggressors, including oppressive governments and organized crime rings around the world.


Scope of Threats

An array of potential threats surrounds online users, and this cheat sheet focuses on political and legal threats that users might face by using these online services, especially social networking and communication platforms. The various reports of imprisonments and even execution for users in some parts of the world simply for using online services must be taken seriously by web developers.


Guidelines

1- Strong Cryptography:

Any online platform that handles user identities, private information or communications must be secured with the use of strong cryptography. User communications must be encrypted in transit and storage. User secrets such as passwords must also be protected using strong, collision-resistant hashing algorithms with increasing work factors, in order to greatly mitigate the risks of exposed credentials as well as proper integrity control.

To protect data in transit, developers must use and adhere to TSL/SSL best practices such as verified certificates, adequately protected private keys, usage of strong ciphers only, informative and clear warnings to users, as well as sufficient key lengths.

Private data must be encrypted in storage as well, using keys with sufficient lengths and under strict access conditions, both technical and procedural. User credentials must be hashed regardless of whether or not they are encrypted in storage.

For detailed guides about strong cryptography and best practices, read the following OWASP references:

1- Cryptographic Storage Cheat Sheet

2- Authentication Cheat Sheet

3- Transport Layer Protection Cheat Sheet

4- Guide to Cryptography

5- Testing for TLS/SSL


Support HTTP Strict Transport Security

HTTP Strict Transport Security (HSTS) is an HTTP header set by the server indicating to the user agent that only secure (HTTPS) connections are accepted, prompting the user agent to change all insecure HTTP links to secure HTTPS ones, and also forcing the compliant user agent to fail-safe by refusing any TLS/SSL connection that is not trusted by the user.

HSTS has average support on popular user agent, such as Mozilla Firefox and Google Chrome. Nevertheless, it remains very useful for users who are in consistent fear of spying and Man in the Middle Attacks.

If it is impractical to force HSTS on all users, web developers should at least give users the choice to enable it if they wish to make use of it.

For more details regarding HSTS, please visit:

1- HTTP Strict Transport Security in Wikipedia

2- IETF Draft for HSTS


Digital Certificate Pinning

Certificate Pinning is the practice of hardcoding or storing a pre-defined set of hashes for digital certificates/public keys in the user agent (be it web browser, mobile app or browser plugin) such that only the predefined certificates are used for secured communication, and any other certificate will fail, even if the user trusted (implicitly or explicitly) the other certificates.

Some advantages for certificate pinning are:

- In the event of CA compromise, in which a compromised CA trusted by a user can issue certificates for any domain, allowing evil perpetrators to eavesdrop on users.

- In environments where users are forced to accept a potentially-malicious root CA, such as corporate environments or national PKI schemes.

- In applications where the target demographic may not understand certificate warnings, and is likely to just allow any invalid certificate.

For details regarding certificate pinning, please refer to the following:

1- Public Key Pinning Extension for HTTP draft-ietf-websec-key-pinning-02

2- Securing the SSL channel against man-in-the-middle attacks: Future technologies - HTTP Strict Transport Security and and Pinning of Certs, by Tobias Gondrom