How a password changed my life.

How a password changed my life.The following events occurred between ☹ and ☺.

“How could she do something like this to me?” said a voice in my head. All the time. Everyday.

Back in 2011, when everything had gradients, iOS icons made sense, and people used deodorants, I was stuck in middle of a pretty bad depression due to my divorce.

ThankfullyI think I was smart enough (and had great people around me) so I managed my way out.


One day I walk into the office, and my day begins at my computer screen. It was all great, until I saw this message:

Your password has expired.
Click ‘Change password’ to change your password.

No shit. I thought clicking ‘Change password’ was gonna do something else.

I read this dumb message in my mind with angry grandpa voice: The damn password has expired.

At my workplace, the Microsoft Exchange server is configured to askthousands of employees around the planet to change their passwords. Every 30 days.

Here is the horse-shit: The server forces us to use at least oneUPPERCASE character, at least one lowercase alphabeticcharacter, at least one symbol and at least one number. Oh, and the whole damn thing can’t be less than 8 characters. And I can’t use any of the same passwords I’ve used in the last 3 months.

I was furious that morning. Tuesday, 9:40 a.m. -It was so hot that my torso was already sweaty even though I just got to work. I was late. I was still wearing my helmet. I think I forgot breakfast. Something tastes like cigarette in my mouth. I need to get shit done before my 10 a.m. meeting and all I have in front of me is a huge waste of my time.


So there it was… This input field with a pulsating cursor, waiting for me to type a password that I’ll have to re-enter for the next 30 days. Many times during the day.

Then, letting all the frustration go, I remembered a tip I heard form my former boss.

I’m gonna use a password to change my life.

It was obvious that I couldn’t focus on getting things done with my current lifestyle and mood. Of course, there were clear indicators of what I needed to do -or what I had to achieve- in order to regain control of my life, but we often don’t pay attention to these clues.

My password became the indicator. My password reminded me that I shouldn’t let myself be victim of my recent break up, and that I’m strong enough to do something about it.

My password became: Forgive@h3r

I had to type this statement several times a day. Each time my computer would lock. Each time my screensaver with her photo would appear. Each time I would come back from eating lunch alone.

In my mind, I went with the mantra that I didn’t type a password. In my mind, I wrote “Forgive her” everyday, for one month.


That simple action changed the way I looked at my ex wife. That constant reminder that I should forgive her, led me to accept the way things happened at the end of my marriage, and embrace a new way of dealing with the depression that I was drowning into.

In the following days, my mood improved drastically. By the end of the 2nd week, I noticed that this password became less powerful, and it started to lose its effect. A quick refresh of this ‘mantra’ helped me. I thought to myself I forgive her as I typed it, every time. The healing effect of it came back almost immediately.


One month later, my dear exchange server asked me again to renew my password. I thought about the next thing I had to get done.

My password became Quit@smoking4ever

And guess what happened. I shit you not. I quit smoking overnight.This password was a painful one to type during that month, but doing it helped me to yell at myself in my mind, as I typed that statement. It motivated me to follow my monthly goal.

One month later, my password became Save4trip@thailand

Guess where I went 3 months later. Thailand. With savings.

Thank you, password.

So, I learned that I can truly change my life if I play it right. I kept doing this repeatedly month after month, with great results.

Here is an extract of what some of my passwords have been in the last 2 years, so you get an idea of how my life has changed, thanks to this method:

  • Forgive@her ← to my ex-wife, who started it all.
  • Quit@smoking4ever ← it worked.
  • Save4trip@thailand ← it worked.
  • Eat2times@day ← it never worked, still fat.
  • Sleep@before12 ← it worked.
  • Ask@her4date ← it worked. I fell in love again.
  • No@drinking2months ← it worked. I feel better.
  • Get@c4t! ← it worked. I have a beautiful cat.
  • Facetime2mom@sunday ← it worked. I talk with my mom every week.

And the one for last month:

  • Save4@ring ← Yep. Life is gonna change again, soon.

I still await very anxiously each month so I can change my password into something that I need to get done.

This method has consistently worked for me for the last 2 years.

https://medium.com/@manicho/how-a-password-changed-my-life-7af5d5f28038

Advertisements

Global Cyber Attack Maps

1 – Cyber Warfare Real Time Map by Kaspersky

2 – Top Daily DDoS Attacks Worldwide by Google

3 – Security Tachometer by Deutche Telekom

4 – Cyberfeed Live Botnet Map by AnubisNetworks

5 – Real-time Web Monitor by Akamai

6 – IpViking Live Map by Norse

7 – Honeypots from the Honeynet Project

8 – Global Activity Maps by Arbor

9 – Global Botnet Threat Activity Map by Trend Micro

10 – DDoS Attacks by ShadowServer

11 – Internet Malicious Activity Maps by TeamCymru

12 – Globe and WorldMap by F-Secure

http://luizfirmino.blogspot.com/2014/06/global-cyber-attack-maps.html

How to do a basic SQL injection

Here is a video showing you how to perform and SQL injection the vulnerable application is called DVWA and can be downloaded from the following address: http://www.dvwa.co.uk/

 

How to do a basic SQL injection

Salted Password Hashing – Doing it Right

Content

  1. Introduction
  2. What is Password Hashing?
  3. How Hashes are Cracked
  4. Adding Salt
  5. Other Security Measures
  6. Frequently Asked Questions
  7. Password Hashing Sample Code

1. Introduction

If you’re a web developer, you’ve probably had to make a user account system. The most important aspect of a user account system is how user passwords are protected. User account databases are hacked frequently, so you absolutely must do something to protect your users’ passwords if your website is ever breached. The best way to protect passwords is to employ salted password hashing. This page will explain how to do it properly.

There are a lot of conflicting ideas and misconceptions on how to do password hashing properly, probably due to the abundance of misinformation on the web. Password hashing is one of those things that’s so simple, but yet so many people get wrong. With this page, I hope to explain not only the correct way to do it, but why it should be done that way.

2. What is Password Hashing?

hash("hello") = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
hash("hbllo") = 58756879c05c68dfac9866712fad6a93f8146f337a69afe7dd238f3364946366
hash("waltz") = c0e81794384491161f1777c232bc6bd9ec38f616560b120fda8e90f383853542

Hash algorithms are one way functions. They turn any amount of data into a fixed-length “fingerprint” that cannot be reversed. They also have the property that if the input changes by even a tiny bit, the resulting hash is completely different (see the example above). This is great for protecting passwords, because we want to store passwords in an encrypted form that’s impossible to decrypt, but at the same time, we need to be able to verify that a user’s password is correct.

The general workflow for account registration and authentication in a hash-based account system is as follows:

  1. The user creates an account.
  2. Their password is hashed and stored in the database. At no point is the plain-text (unencrypted) password ever written to the hard drive.
  3. When the user attempts to login, the hash of the password they entered is checked against the hash of their real password (retrieved from the database).
  4. If the hashes match, the user is granted access. If not, the user is told they entered invalid login credentials.
  5. Steps 3 and 4 repeat everytime someone tries to login to their account.

In step 4, never tell the user if it was the username or password they got wrong. Always display a generic message like “Invalid username or password.” This prevents attackers from enumerating valid usernames without knowing their passwords.

It should be noted that the hash functions used to protect passwords are not the same as the hash functions you may have seen in a data structures course. The hash functions used to implement data structures such as hash tables are designed to be fast, not secure. Only cryptographic hash functions may be used to implement password hashing. Hash functions like SHA256, SHA512, RipeMD, and WHIRLPOOL are cryptographic hash functions.

It is easy to think that all you have to do is run the password through a cryptographic hash function and your users’ passwords will be secure. This is far from the truth. There are many ways to recover passwords from plain hashes very quickly. There are several easy-to-implement techniques that make these “attacks” much less effective. To motivate the need for these techniques, consider this very website. On the front page, you can submit a list of hashes to be cracked, and receive results in less than a second. Clearly, simply hashing the password does not meet our needs for security.

The next section will discuss some of the common attacks used to crack plain password hashes.

3. How Hashes are Cracked

Dictionary Attacks

Trying apple       : fail
Trying blueberry   : fail
Trying 1234567     : fail
......
Trying letmein     : fail
Trying qwerty      : Success!

Brute Force Attacks

Trying aaaa        : fail
Trying aaab        : fail
Trying aaac        : fail
Trying aaad        : fail
......			
Trying acdb        : fail
Trying acdc        : Success!

The simplest way to crack a hash is to try to guess the password, hashing each guess, and checking if the guess’s hash equals the hash being cracked. If the hashes are equal, the guess is the password. The two most common ways of guessing passwords are dictionary attacks and brute-force attacks.

A dictionary attack uses a file containing words, phrases, common passwords, and other strings that are likely to be used as a password. Each word in the file is hashed, and its hash is compared to the password hash. If they match, that word is the password. These dictionary files are constructed by extracting words from large bodies of text, and even from real databases of passwords. Further processing is often applied to dictionary files, such as replacing words with their “leet speak” equivalents (“hello” becomes “h3110”), to make them more effective.

A brute-force attack tries every possible combination of characters up to a given length. These attacks are very computationally expensive, and are usually the least efficient in terms of hashes cracked per processor time, but they will always eventually find the password. Passwords should be long enough that searching through all possible character strings to find it will take too long to be worthwhile.

There is no way to prevent dictionary attacks or brute force attacks. They can be made less effective, but there isn’t a way to prevent them altogether. If your password hashing system is secure, the only way to crack the hashes will be to run a dictionary or brute-force attack on each hash.

Lookup Tables

Searching: 5f4dcc3b5aa765d61d8327deb882cf99: FOUND: password5
Searching: 6cbe615c106f422d23669b610b564800: not in database
Searching: 630bf032efe4507f2c57b280995925a9: FOUND: letMEin12 
Searching: 386f43fab5d096a7a66d67c8f213e5ec: FOUND: mcd0nalds
Searching: d5ec75d5fe70d428685510fae36492d9: FOUND: p@ssw0rd!

Lookup tables are an extremely effective method for cracking many hashes of the same type very quickly. The general idea is to pre-compute the hashes of the passwords in a password dictionary and store them, and their corresponding password, in a lookup table data structure. A good implementation of a lookup table can process hundreds of hash lookups per second, even when they contain many billions of hashes.

If you want a better idea of how fast lookup tables can be, try cracking the following sha256 hashes with CrackStation’sfree hash cracker.

These hashes can be easily cracked in less than 1 second:

c11083b4b0a7743af748c85d343dfee9fbb8b2576c05f3a7f0d632b0926aadfc
08eac03b80adc33dc7d8fbe44b7c7b05d3a2c511166bdb43fcb710b03ba919e7
e4ba5cbd251c98e6cd1c23f126a3b81d8d8328abc95387229850952b3ef9f904
5206b8b8a996cf5320cb12ca91c7b790fba9f030408efe83ebb83548dc3007bd
d53d8d0632cd64e595b2cc9709bd580e4d323cd65ebbfaa778b3252c761ba1b8 

You can generate your own hash of your frequently used password with http://www.hashemall.com/[^] and try to crack it with the above mentioned tool. 

Reverse Lookup Tables

Searching for hash(apple) in users' hash list...     : Matches [alice3, 0bob0, charles8]
Searching for hash(blueberry) in users' hash list... : Matches [usr10101, timmy, john91]
Searching for hash(letmein) in users' hash list...   : Matches [wilson10, dragonslayerX, joe1984]
Searching for hash(s3cr3t) in users' hash list...    : Matches [bruce19, knuth1337, john87]
Searching for hash(z@29hjja) in users' hash list...  : No users used this password

This attack allows an attacker to apply a dictionary or brute-force attack to many hashes at the same time, without having to pre-compute a lookup table.

First, the attacker creates a lookup table that maps each password hash from the compromised user account database to a list of users who had that hash. The attacker then hashes each password guess and uses the lookup table to get a list of users whose password was the attacker’s guess. This attack is especially effective because it is common for many users to have the same password.

Rainbow Tables

Rainbow tables are a time-memory trade-off technique. They are like lookup tables, except that they sacrifice hash cracking speed to make the lookup tables smaller. Because they are smaller, the solutions to more hashes can be stored in the same amount of space, making them more effective. Rainbow tables that can crack any md5 hash of a password up to 8 characters long exist.

Next, we’ll look at a technique called salting, which makes it impossible to use lookup tables and rainbow tables to crack a hash.

4. Adding Salt

hash("hello")                    = 2cf24dba5fb0a30e26e83b2ac5b9e29e1b161e5c1fa7425e73043362938b9824
hash("hello" + "QxLUF1bgIAdeQX") = 9e209040c863f84a31e719795b2577523954739fe5ed3b58a75cff2127075ed1
hash("hello" + "bv5PehSMfV11Cd") = d1d3ec2e6f20fd420d50e2642992841d8338a314b8ea157c9e18477aaef226ab
hash("hello" + "YYLmfY6IehjZMQ") = a49670c3c18b9e079b9cfaf51634f563dc8ae3070db2c4a8544305df1b60f007

Lookup tables and rainbow tables only work because each password is hashed the exact same way. If two users have the same password, they’ll have the same password hashes. We can prevent these attacks by randomizing each hash, so that when the same password is hashed twice, the hashes are not the same.

We can randomize the hashes by appending or prepending a random string, called a salt, to the password before hashing. As shown in the example above, this makes the same password hash into a completely different string every time. To check if a password is correct, we need the salt, so it is usually stored in the user account database along with the hash, or as part of the hash string itself.

The salt does not need to be secret. Just by randomizing the hashes, lookup tables, reverse lookup tables, and rainbow tables become ineffective. An attacker won’t know in advance what the salt will be, so they can’t pre-compute a lookup table or rainbow table. If each user’s password is hashed with a different salt, the reverse lookup table attack won’t work either.

In the next section, we’ll look at how salt is commonly implemented incorrectly.

The WRONG Way: Short Salt & Salt Reuse

This section covers another common password hashing misconception: wacky combinations of hash algorithms. It’s easy to get carried away and try to combine different hash functions, hoping that the result will be more secure. In practice, though, there is very little benefit to doing it. All it does is create interoperability problems, and can sometimes even make the hashes less secure. Never try to invent your own crypto, always use a standard that has been designed by experts. Some will argue that using multiple hash functions makes the process of computing the hash slower, so cracking is slower, but there’s a better way to make the cracking process slower as we’ll see later.

Here are some examples of poor wacky hash functions I’ve seen suggested in forums on the internet.

  • md5(sha1(password))
  • md5(md5(salt) + md5(password))
  • sha1(sha1(password))
  • sha1(str_rot13(password + salt))
  • md5(sha1(md5(md5(password) + sha1(password)) + md5(password)))

Do not use any of these.

Note: This section has proven to be controversial. I’ve received a number of emails arguing that wacky hash functions are a good thing, because it’s better if the attacker doesn’t know which hash function is in use, it’s less likely for an attacker to have pre-computed a rainbow table for the wacky hash function, and it takes longer to compute the hash function.

An attacker cannot attack a hash when he doesn’t know the algorithm, but note Kerckhoffs’s principle, that the attacker will usually have access to the source code (especially if it’s free or open source software), and that given a few password-hash pairs from the target system, it is not difficult to reverse engineer the algorithm. It does take longer to compute wacky hash functions, but only by a small constant factor. It’s better to use an iterated algorithm that’s designed to be extremely hard to parallelize (these are discussed below). And, properly salting the hash solves the rainbow table problem.

If you really want to use a standardized “wacky” hash function like HMAC, then it’s OK. But if your reason for doing so is to make the hash computation slower, read the section below about key stretching first.

Compare these minor benefits to the risks of accidentally implementing a completely insecure hash function and the interoperability problems wacky hashes create. It’s clearly best to use a standard and well-tested algorithm.

Hash Collisions

Because hash functions map arbitrary amounts of data to fixed-length strings, there must be some inputs that hash into the same string. Cryptographic hash functions are designed to make these collisions incredibly difficult to find. From time to time, cryptographers find “attacks” on hash functions that make finding collisions easier. A recent example is the MD5 hash function, for which collisions have actually been found. (Read more: MD5 considered harmful today)

Collision attacks are a sign that it may be more likely for a string other than the user’s password to have the same hash. However, finding collisions in even a weak hash function like MD5 requires a lot of dedicated computing power, so it is very unlikely that these collisions will happen “by accident” in practice. A password hashed using MD5 and salt is, for all practical purposes, just as secure as if it were hashed with SHA256 and salt. Nevertheless, it is a good idea to use a more secure hash function like SHA256, SHA512, RipeMD, or WHIRLPOOL if possible.

The RIGHT Way: How to Hash Properly

This section describes exactly how passwords should be hashed. The first subsection covers the basics—everything that is absolutely necessary. The following subsections explain how the basics can be augmented to make the hashes even harder to crack.

The Basics: Hashing with Salt

Warning: Do not just read this section. You absolutely must implement the stuff in the next section: “Making Password Cracking Harder: Slow Hash Functions”.

We’ve seen how malicious hackers can crack plain hashes very quickly using lookup tables and rainbow tables. We’ve learned that randomizing the hashing using salt is the solution to the problem. But how do we generate the salt, and how do we apply it to the password?

Salt should be generated using a Cryptographically Secure Pseudo-Random Number Generator (CSPRNG). CSPRNGs are very different than ordinary pseudo-random number generators, like the “C” language’s rand()function. As the name suggests, CSPRNGs are designed to be cryptographically secure, meaning they provide a high level of randomness and are completely unpredictable. We don’t want our salts to be predictable, so we must use a CSPRNG. The following table lists some CSPRNGs that exist for some popular programming platforms.

Platform CSPRNG
PHP mcrypt_create_ivopenssl_random_pseudo_bytes
Java java.security.SecureRandom
.NET (C#, VB.NET) System.Security.Cryptography.RNGCryptoServiceProvider
Ruby SecureRandom
Python os.urandom
Perl Math::Random::Secure
C/C++ (Windows API) CryptGenRandom
Any language on GNU/Linux or Unix Read from /dev/random or /dev/urandom

The salt needs to be unique per-user per-password. Every time a user creates an account or changes their password, the password should be hashed using a new random salt. Never reuse a salt. The salt also needs to be long, so that there are many possible salts. As a rule of thumb, make your salt is at least as long as the hash function’s output. The salt should be stored in the user account table alongside the hash.

To Store a Password

  1. Generate a long random salt using a CSPRNG.
  2. Prepend the salt to the password and hash it with a standard cryptographic hash function such as SHA256.
  3. Save both the salt and the hash in the user’s database record.

To Validate a Password

  1. Retrieve the user’s salt and hash from the database.
  2. Prepend the salt to the given password and hash it using the same hash function.
  3. Compare the hash of the given password with the hash from the database. If they match, the password is correct. Otherwise, the password is incorrect.

At the bottom of this page, there are implementations of salted password hashing in PHP, C#, Java, and Ruby.

In a Web Application, always hash on the server.

If you are writing a web application, you might wonder where to hash. Should the password be hashed in the user’s browser with JavaScript, or should it be sent to the server “in the clear” and hashed there?

Even if you are hashing the user’s passwords in JavaScript, you still have to hash the hashes on the server. Consider a website that hashes users’ passwords in the user’s browser without hashing the hashes on the server. To authenticate a user, this website will accept a hash from the browser and check if that hash exactly matches the one in the database. This seems more secure than just hashing on the server, since the users’ passwords are never sent to the server, but it’s not.

The problem is that the client-side hash logically becomes the user’s password. All the user needs to do to authenticate is tell the server the hash of their password. If a bad guy got a user’s hash, he could use it to authenticate to the server, without knowing the user’s password! So, if the bad guy somehow steals the database of hashes from this hypothetical website, he’ll have immediate access to everyone’s accounts without having to guess any passwords.

This isn’t to say that you shouldn’t hash in the browser, but if you do, you absolutely have to hash on the server too. Hashing in the browser is certainly a good idea, but consider the following points for your implementation:

  • Client-side password hashing is not a substitute for HTTPS (SSL/TLS). If the connection between the browser and the server is insecure, a man-in-the-middle can modify the JavaScript code as it is downloaded to remove the hashing functionality and get the user’s password.
  • Some web browsers don’t support JavaScript, and some users disable JavaScript in their browser. So for maximum compatibility, your app should detect whether or not the browser supports JavaScript and emulate the client-side hash on the server if it doesn’t.
  • You need to salt the client-side hashes too. The obvious solution is to make the client-side script ask the server for the user’s salt. Don’t do that, because it lets the bad guys check if a username is valid without knowing the password. Since you’re hashing and salting (with a good salt) on the server too, it’s OK to use the username (or email) concatenated with a site-specific string (e.g. domain name) as the client-side salt.

Making Password Cracking Harder: Slow Hash Functions

Salt ensures that attackers can’t use specialized attacks like lookup tables and rainbow tables to crack large collections of hashes quickly, but it doesn’t prevent them from running dictionary or brute-force attacks on each hash individually. High-end graphics cards (GPUs) and custom hardware can compute billions of hashes per second, so these attacks are still very effective. To make these attacks less effective, we can use a technique known as key stretching.

The idea is to make the hash function very slow, so that even with a fast GPU or custom hardware, dictionary and brute-force attacks are too slow to be worthwhile. The goal is to make the hash function slow enough to impede attacks, but still fast enough to not cause a noticeable delay for the user.

Key stretching is implemented using a special type of CPU-intensive hash function. Don’t try to invent your own–simply iteratively hashing the hash of the password isn’t enough as it can be parallelized in hardware and executed as fast as a normal hash. Use a standard algorithm like PBKDF2 or bcrypt. You can find a PHP implementation of PBKDF2 here.

These algorithms take a security factor or iteration count as an argument. This value determines how slow the hash function will be. For desktop software or smartphone apps, the best way to choose this parameter is to run a short benchmark on the device to find the value that makes the hash take about half a second. This way, your program can be as secure as possible without affecting the user experience.

If you use a key stretching hash in a web application, be aware that you will need extra computational resources to process large volumes of authentication requests, and that key stretching may make it easier to run a Denial of Service (DoS) attack on your website. I still recommend using key stretching, but with a lower iteration count. You should calculate the iteration count based on your computational resources and the expected maximum authentication request rate. The denial of service threat can be eliminated by making the user solve a CAPTCHA every time they log in. Always design your system so that the iteration count can be increased or decreased in the future.

If you are worried about the computational burden, but still want to use key stretching in a web application, consider running the key stretching algorithm in the user’s browser with JavaScript. The Stanford JavaScript Crypto Libraryincludes PBKDF2. The iteration count should be set low enough that the system is usable with slower clients like mobile devices, and the system should fall back to server-side computation if the user’s browser doesn’t support JavaScript. Client-side key stretching does not remove the need for server-side hashing. You must hash the hash generated by the client the same way you would hash a normal password.

Impossible-to-crack Hashes: Keyed Hashes and Password Hashing Hardware

As long as an attacker can use a hash to check whether a password guess is right or wrong, they can run a dictionary or brute-force attack on the hash. The next step is to add a secret key to the hash so that only someone who knows the key can use the hash to validate a password. This can be accomplished two ways. Either the hash can be encrypted using a cipher like AES, or the secret key can be included in the hash using a keyed hash algorithm like HMAC.

This is not as easy as it sounds. The key has to be kept secret from an attacker even in the event of a breach. If an attacker gains full access to the system, they’ll be able to steal the key no matter where it is stored. The key must be stored in an external system, such as a physically separate server dedicated to password validation, or a special hardware device attached to the server such as the YubiHSM.

I highly recommend this approach for any large scale (more than 100,000 users) service. I consider it necessary for any service hosting more than 1,000,000 user accounts.

If you can’t afford multiple dedicated servers or special hardware devices, you can still get some of the benefits of keyed hashes on a standard web server. Most databases are breached using SQL Injection Attacks, which, in most cases, don’t give attackers access to the local filesystem (disable local filesystem access in your SQL server if it has this feature). If you generate a random key and store it in a file that isn’t accessible from the web, and include it into the salted hashes, then the hashes won’t be vulnerable if your database is breached using a simple SQL injection attack. Don’t hard-code a key into the source code, generate it randomly when the application is installed. This isn’t as secure as using a separate system to do the password hashing, because if there are SQL injection vulnerabilities in a web application, there are probably other types, such as Local File Inclusion, that an attacker could use to read the secret key file. But, it’s better than nothing.

Please note that keyed hashes do not remove the need for salt. Clever attackers will eventually find ways to compromise the keys, so it is important that hashes are still protected by salt and key stretching.

4. Other Security Measures

Password hashing protects passwords in the event of a security breach. It does not make the application as a whole more secure. Much more must be done to prevent the password hashes (and other user data) from being stolen in the first place.

Even experienced developers must be educated in security in order to write secure applications. A great resource for learning about web application vulnerabilities is The Open Web Application Security Project (OWASP). A good introduction is the OWASP Top Ten Vulnerability List. Unless you understand all the vulnerabilities on the list, do not attempt to write a web application that deals with sensitive data. It is the employer’s responsibility to ensure all developers are adequately trained in secure application development.

Having a third party “penetration test” your application is a good idea. Even the best programmers make mistakes, so it always makes sense to have a security expert review the code for potential vulnerabilities. Find a trustworthy organization (or hire staff) to review your code on a regular basis. The security review process should begin early in an application’s life and continue throughout its development.

It is also important to monitor your website to detect a breach if one does occur. I recommend hiring at least one person whose full time job is detecting and responding to security breaches. If a breach goes undetected, the attacker can make your website infect visitors with malware, so it is extremely important that breaches are detected and responded to promptly.

5. Frequently Asked Questions

Do Use

  • The PHP source code, Java source code, C# source code or the Ruby source code at the bottom of this page.
  • OpenWall’s Portable PHP password hashing framework.
  • Any modern well-tested cryptographic hash algorithm, such as SHA256, SHA512, RipeMD, WHIRLPOOL, SHA3, etc.
  • Well-designed key stretching algorithms such as PBKDF2bcrypt, and scrypt.
  • Secure versions of crypt ($2y$, $5$, $6$)

Don’t Use

  • Outdated hash functions like MD5 or SHA1.
  • Insecure versions of crypt ($1$, $2$, $2x$, $3$).
  • Any algorithm that you designed yourself. Only use technology that is in the public domain and has been well-tested by experienced cryptographers.

Even though there are no cryptographic attacks on MD5 or SHA1 that make their hashes easier to crack, they are old and are widely considered (somewhat incorrectly) to be inadequate for password storage. So I don’t recommend using them. An exception to this rule is PBKDF2, which is frequently implemented using SHA1 as the underlying hash function.

How should I allow users to reset their password when they forget it?

It is my personal opinion that all password reset mechanisms in widespread use today are insecure. If you have high security requirements, such as an encryption service would, do not let the user reset their password.

Most websites use an email loop to authenticate users who have forgotten their password. To do this, generate a random single-use token that is strongly tied to the account. Include it in a password reset link sent to the user’s email address. When the user clicks a password reset link containing a valid token, prompt them for a new password. Be sure that the token is strongly tied to the user account so that an attacker can’t use a token sent to his own email address to reset a different user’s password.

The token must be set to expire in 15 minutes or after it is used, whichever comes first. It is also a good idea to expire any existing password tokens when the user logs in (they remembered their password) or requests another reset token. If a token doesn’t expire, it can be forever used to break into the user’s account. Email (SMTP) is a plain-text protocol, and there may be malicious routers on the internet recording email traffic. And, a user’s email account (including the reset link) may be compromised long after their password has been changed. Making the token expire as soon as possible reduces the user’s exposure to these attacks.

Attackers will be able to modify the tokens, so don’t store the user account information or timeout information in them. They should be an unpredictable random binary blob used only to identify a record in a database table.

Never send the user a new password over email. Remember to pick a new random salt when the user resets their password. Don’t re-use the one that was used to hash their old password.

What should I do if my user account database gets leaked/hacked?

Your first priority is to determine how the system was compromised and patch the vulnerability the attacker used to get in. If you do not have experience responding to breaches, I highly recommend hiring a third-party security firm.

It may be tempting to cover up the breach and hope nobody notices. However, trying to cover up a breach makes you look worse, because you’re putting your users at further risk by not informing them that their passwords and other personal information may be compromised. You must inform your users as soon as possible—even if you don’t yet fully understand what happened. Put a notice on the front page of your website that links to a page with more detailed information, and send a notice to each user by email if possible.

Explain to your users exactly how their passwords were protected—hopefully hashed with salt—and that even though they were protected with a salted hash, a malicious hacker can still run dictionary and brute force attacks on the hashes. Malicious hackers will use any passwords they find to try to login to a user’s account on a different website, hoping they used the same password on both websites. Inform your users of this risk and recommend that they change their password on any website or service where they used a similar password. Force them to change their password for your service the next time they log in. Most users will try to “change” their password to the original password to get around the forced change quickly. Use the current password hash to ensure that they cannot do this.

It is likely, even with salted slow hashes, that an attacker will be able to crack some of the weak passwords very quickly. To reduce the attacker’s window of opportunity to use these passwords, you should require, in addition to the current password, an email loop for authentication until the user has changed their password. See the previous question, “How should I allow users to reset their password when they forget it?” for tips on implementing email loop authentication.

Also tell your users what kind of personal information was stored on the website. If your database includes credit card numbers, you should instruct your users to look over their recent and future bills closely and cancel their credit card.

What should my password policy be? Should I enforce strong passwords?

If your service doesn’t have strict security requirements, then don’t limit your users. I recommend showing users information about the strength of their password as they type it, letting them decide how secure they want their password to be. If you have special security needs, enforce a minimum length of 12 characters and require at least two letters, two digits, and two symbols.

Do not force your users to change their password more often than once every six months, as doing so creates “user fatigue” and makes users less likely to choose good passwords. Instead, train users to change their password whenever they feel it has been compromised, and to never tell their password to anyone. If it is a business setting, encourage employees to use paid time to memorize and practice their password.

If an attacker has access to my database, can’t they just replace the hash of my password with their own hash and login?

Yes, but if someone has access to your database, they probably already have access to everything on your server, so they wouldn’t need to login to your account to get what they want. The purpose of password hashing (in the context of a website) is not to protect the website from being breached, but to protect the passwords if a breach does occur.

You can prevent hashes from being replaced during a SQL injection attack by connecting to the database with two users with different permissions. One for the ‘create account’ code and one for the ‘login’ code. The ‘create account’ code should be able to read and write to the user table, but the ‘login’ code should only be able to read.

Why do I have to use a special algorithm like HMAC? Why can’t I just append the password to the secret key?

Hash functions like MD5, SHA1, and SHA2 use the Merkle–Damgård construction, which makes them vulnerable to what are known as length extension attacks. This means that given a hash H(X), an attacker can find the value of H(pad(X) + Y), for any other string Y, without knowing X. pad(X) is the padding function used by the hash.

This means that given a hash H(key + message), an attacker can compute H(pad(key + message) + extension), without knowing the key. If the hash was being used as a message authentication code, using the key to prevent an attacker from being able to modify the message and replace it with a different valid hash, the system has failed, since the attacker now has a valid hash of message + extension.

It is not clear how an attacker could use this attack to crack a password hash quicker. However, because of the attack, it is considered bad practice to use a plain hash function for keyed hashing. A clever cryptographer may one day come up with a clever way to use these attacks to make cracking faster, so use HMAC.

Should the salt come before or after the password?

It doesn’t matter, but pick one and stick with it for interoperability’s sake. Having the salt come before the password seems to be more common.

Why does the hashing code on this page compare the hashes in “length-constant” time?

Comparing the hashes in “length-constant” time ensures that an attacker cannot extract the hash of a password in an on-line system using a timing attack, then crack it off-line.

The standard way to check if two sequences of bytes (strings) are the same is to compare the first byte, then the second, then the third, and so on. As soon as you find a byte that isn’t the same for both strings, you know they are different and can return a negative response immediately. If you make it through both strings without finding any bytes that differ, you know the strings are the same and can return a positive result. This means that comparing two strings can take a different amount of time depending on how much of the strings match.

For example, a standard comparison of the strings “xyzabc” and “abcxyz” would immediately see that the first character is different and wouldn’t bother to check the rest of the string. On the other hand, when the strings “aaaaaaaaaaB” and “aaaaaaaaaaZ” are compared, the comparison algorithm scans through the block of “a” before it determines the strings are unequal.

Suppose an attacker wants to break into an on-line system that rate limits authentication attempts to one attempt per second. Also suppose the attacker knows all of the parameters to the password hash (salt, hash type, etc), except for the hash and (obviously) the password. If the attacker can get a precise measurement of how long it takes the on-line system to compare the hash of the real password with the hash of a password the attacker provides, he can use the timing attack to extract part of the hash and crack it using an offline attack, bypassing the system’s rate limiting.

First, the attacker finds 256 strings whose hashes begin with every possible byte. He sends each string to the on-line system, recording the amount of time it takes the system to respond. The string that takes the longest will be the one whose hash’s first byte matches the real hash’s first byte. The attacker now knows the first byte, and can continue the attack in a similar manner on the second byte, then the third, and so on. Once the attacker knows enough of the hash, he can use his own hardware to crack it, without being rate limited by the system.

It might seem like it would be impossible to run a timing attack over a network. However, it has been done, and has been shown to be practical. That’s why the code on this page compares strings in a way that takes the same amount of time no matter how much of the strings match.  

How does the SlowEquals code work?

The previous question explains why SlowEquals is necessary, this one explains how the code actually works.

private static boolean slowEquals(byte[] a, byte[] b)
{
    int diff = a.length ^ b.length;
    for(int i = 0; i < a.length && i < b.length; i++)
    diff |= a[i] ^ b[i];
    return diff == 0;
}

The code uses the XOR “^” operator to compare integers for equality, instead of the “==” operator. The reason why is explained below. The result of XORing two integers will be zero if and only if they are exactly the same. This is because 0 XOR 0 = 0, 1 XOR 1 = 0, 0 XOR 1 = 1, 1 XOR 0 = 1. If we apply that to all the bits in both integers, the result will be zero only if all the bits matched.

So, in the first line, if a.length is equal to b.length, the diff variable will get a zero value, but if not, it will get some non-zero value. Next, we compare the bytes using XOR, and OR the result into diff. This will set diff to a non-zero value if the bytes differ. Because ORing never un-sets bits, the only way diff will be zero at the end of the loop is if it was zero before the loop began (a.length == b.length) and all of the bytes in the two arrays match (none of the XORs resulted in a non-zero value).

The reason we need to use XOR instead of the “==” operator to compare integers is that “==” is usually translated/compiled/interpreted as a branch. For example, the C code “diff &= a == b” might compile to the following x86 assembly:

MOV EAX, [A]
CMP [B], EAX
JZ equal
JMP done
equal:
AND [VALID], 1
done:
AND [VALID], 0

The branching makes the code execute in a different amount of time depending on the equality of the integers and the CPU’s internal branch prediction state.

The C code “diff |= a ^ b” should compile to something like the following, whose execution time does not depend on the equality of the integers:  

MOV EAX, [A]
XOR EAX, [B]
OR [DIFF], EAX

Why bother hashing?

Your users are entering their password into your website. They are trusting you with their security. If your database gets hacked, and your users’ passwords are unprotected, then malicious hackers can use those passwords to compromise your users’ accounts on other websites and services (most people use the same password everywhere). It’s not just your security that’s at risk, it’s your users’. You are responsible for your users’ security.

6. Password Hashing Sample Code

The below sample codes will link back to author’s original website.


Article and code written by Taylor Hornby (Defuse Security), first post at: http://crackstation.net/hashing-security.htm. This article was re-posted as [The Insider News] on 26th Oct 2012 by adriancs, and then, this was re-posted again as Article by adriancs, considering this would reach more audience.

http://www.codeproject.com/Articles/704865/Salted-Password-Hashing-Doing-it-Right

DNS Sinkhole

Overview

DNS sinkhole or black hole DNS is used to spoof DNS servers to prevent resolving host names of specified URLs. This can be achieved by configuring the DNS forwarder to return a false IP address to a specific URL. DNS sinkholing can be used to prevent access of malicious URLs in an enterprise level. The malicious URLs can be blocked by adding a false entry in the DNS and thus there will be a second level of protection. Normally firewalls and proxies are used to block malicious traffic across the organization.

By using the DNS sinkhole technique it is also possible to deny access to any of the websites. This can be used to restrict access to specific sites that violate corporate policies, including social networking, abusive content, etc. When a user tries to access a sinkholed URL, a customised webpage can be shown. This webpage can be created with information detailing the corporate policy restriction and can be hosted on a local server.

A DNS sinkhole can be used to control the C&C traffic and other malicious traffic across the enterprise level. The sinkhole can be used to change the flow to malicious URLs by entering the fake entry in the DNS. These malicious URLs can be gathered from already known C&C servers, through the malware analysis process, open source sites that are providing malicious IP details, etc.

DNS sinkholing is used to provide wrong DNS resolution and alternate the path of the users to different resources instead of the malicious or non-accessible content. A sinkhole is basically a way of redirecting malicious Internet traffic so that it can be captured and analysed by security analysts. Sinkholes are most often used to seize control of botnets by interrupting the DNS names of the botnet that is used by the malware.

Background

DNS is a protocol within the set of standards for how computers exchange data on the Internet and on many private networks, known as the TCP/IP protocol suite. A DNS service is used for routing the domain name of sites with its IP address. A DNS server or name server manages a massive database that maps domain names to IP addresses.

This protocol has a wide variety of applications that has to be passed through the interface that can be interfered. DNS is a hierarchical distributed database that contains information mapping Internet hostnames to IP addresses and vice-versa. Users look up information in the DNS by referencing a resolver library, which sends queries to multiple name servers and also acts as a responder.

The data stored in the DNS is identified by domain names that are organized as a tree according to organizational or administrative boundaries. The domain name of the node is the concatenation of all the labels on the path from the node to the root node. This is represented in a string of labels listed from right to left and separated by dots.

The client server using a DNS mechanism goes around matching the domain names with that of the IP address. This DNS resolution is capable of resolving data from queries. A DNS that is hierarchical in nature is able to solve queries in a manner that is capable of resolving the functionality of a system. The DNS can be used to route the data and can send a diverted request to the server side. This request resolution can be handled on a client basis and can handle an ongoing process.

Architecture

The figure illustrates the DNS flows that occur when an attacker compromises a user and this infected user tries to contact a botnet.

The DNS sinkhole bypasses the DNS request and provides the response that is configured by the DNS sinkhole administrator. It doesn’t allow domain to be resolved by the domain’s authoritative owner. Instead, the DNS sinkhole intercepts the DNS request and responds with an authoritative answer configured by the organization.

With the basic sinkhole functionality, the malware on the infected machine attempts to initiate a connection to a system hosted on a URL, i.e., a known malicious domain configured in the DNS sinkhole. But the request is not passed to the malicious URL, instead it is sent to the sinkhole which in turn responds with an IP of the local host, forcing the client to connect to itself instead of the malicious IP. The client is unable to contact the malicious site and the command and control connection with the botnet is never established. The bot master will be unaware that the compromise has occurred.

After this step, the preparation, detection and partial containment is finished. Containment is partial because the compromised computer may still attempt to attack internal computers. Therefore, additional analysis and eradication steps should be carried out by the corresponding teams.

Functionalities

A DNS sinkhole has a major set of functionalities that has multiple use cases:

DNS sinkhole redirects user access to a legitimate website that an attacker has secretly inserted with a malicious hidden link, which forces the client to download and execute malicious code without their knowledge.

  • Blocking C&C Channels

When a user tries to connect a C&C server, a Referrer can be popped up, which indicates a direct connection to the domain. This is a good indicator that tells the user is being compromised and the bot is attempting to contact the controller for further malicious commands.

Limitations

There are a number of limitations related with to DNS sinkholing.

In order to block a malware or its traffic by using a DNS sinkhole, it is required by the malware to use the organization’s DNS server itself. A malware with its own hardcoded DNS server and IP address cannot be detected by the DNS sinkholing mechanism. But this drawback can be mitigated by using perimeter firewalls configured to block all other outbound DNS queries rather than organization’s DNS servers.

A DNS sinkhole cannot prevent a malware from being executed and also being spread to other computers. Also, by using a DNS sink hole, a malware cannot be removed from an infected machine.

A DNS sinkhole will be input with the indicators of the malware, and these indicators should be analysed beforehand. Also the malicious IP information gathered from open sources that are to be given into the DNS sinkhole may contain false positives. The sources may contain a URL that is not malicious in nature, and hence it will result in the unwanted restriction to legitimate websites.

A DNS sinkhole should be isolated from the external network, so that the attacker cannot be informed of the fact that their C&C traffic has been mitigated. Otherwise it results in a reverse effect where attackers may manipulate the entries in the DNS sinkhole and use it for malicious purposes.

DNS records should be implemented with time-to-live (TTL) settings with short values, or it may result in users caching the old data for a longer time period.

Scenario

DNS sinkholes were used in several cases in order to mitigate different malware campaigns. It can act as a major tool for eradicating the spreading of malware infection vectors and also can be used to break the C&C connection.

One of the scenarios in which a DNS sinkhole was used is when the infamous CryptoLocker malware was infected in the wild. The CryptoLocker malware is a ransomware that works by encrypting the user’s files with a randomly generated key. It then sends the decryption key to a C&C server, and in normal cases a C&C server with a fixed IP or name would soon be shut down by authorities. In order to overcome this issue, CryptoLocker uses the C&C register’s random-looking domain names at a rather high rate. The domain names are generated with a pseudo-random algorithm that the malware knows. When CryptoLocker executes on a victim’s computer, it connects to one of the domain names in order to contact the C&C.

In this case, the malware knows the domain-generation algorithm and through reverse-engineering the code, it was possible to predict the domain names in advance. Kaspersky “sinkholed” three domain names out of these domain names for a three day time period. With their three domain names, about 1/1000th of the CryptoLocker victims were saved and also they were able to gather the statistics of the infection from across the world.

Understanding DNS Sinkholes – A weapon against malware

DNS Flood DDoS Attack Hit Video Gaming Industry with 90 Million Requests per Second

dns flood ddos attack
Hackers are leveraging large number of compromised machines (a botnet network) to carry out massive DNS Flood DDoS attack against a large Video Gaming Industry website, peaking above 110 Gbps.
 
A US based security solutions provider Incapsula, is protecting a famous Video Gaming website from this high bandwidth DDoS attack from last 48 Hours and according to them, the attack is still continuing. Incapsula has not yet disclosed the name of the video gaming company.

“The attack is still going on – that over 48 hours by now, from what I see it ain’t gonna stop anytime soon,” Incapsula spokesperson wrote in an e-mail to The Hacker News.

DDoS AT 90 MILLION PACKETS/SECOND
The researchers at the security firm noticed a surge of massive DNS Flood DDoS attack on one of its clients, peaking at approximately 90 Mpps (Million Packets Per Second), which is really a very very big number. Majority number of attacking IP addresses belong to China and India. “Good reason to think many are spoofed.” Incapsula told THN.
 
The hackers used a more evil DDoS practice, the DNS flood attack, which is completely different and more responsive from the previously most commonly used DNS amplification attack, both in their methods of execution and in the type of grief they aim to deliver.
 

On one side, where DNS amplification attack is an asymmetrical DDoS attack, in which an attacker set the source address to that of the targeted victim by using spoofed Internet Protocol (IP) of the target, which means the target receives the replies from all the DNS servers that are used, making it the recipient of much larger DNS responses.
 
DNS FLOOD WITHOUT AMPLIFICATION
On the other side, DNS floods attacks are symmetrical DDoS attacks that works by sending thousands of rapid valid DNS requests to the targeted server, thereby giving the server more traffic than it can handle resulting in slower and slower response times for legitimate requests.
 
DNS servers provide the roadmap to the Internet, and help clients find the servers they are looking for, but a DNS floods attempt to exhaust server-side assets (for e.g., memory or CPU) with the large number of UDP requests generated by the malicious scripts running on several compromised botnet machines. The packets sends per seconds are even larger in this case compare to DNS amplification attack.
 
Currently researchers at the DDoS protection service are mitigating with this attack with just one of their servers, that can process upto 170Gbps/100Mpps worth of traffic at an inline rate.
 
Until now, we have seen 50-60Gbps DNS Flood DDoS attack without amplification, but reaching above 110Gbps seems that hackers are making their comeback in really a very big way.
 
As we all have seen that DDoS trend is changing and to perform massive DDoS attacks, hacker are using every tantrum by leveraging the weakness of system applications to compromise them in order to boost the size of their botnet network.
 

LIST OF TRUECRYPT COMPATIBLE ENCRYPTION SOFTWARE

 In light of recent news about Truecrypt being no longer developed, I compiled a list of other encryption programs that are compatible with it.

If you have data that was archived with Truecrypt for long term storage, you should be able to decrypt it with any of the following programs.

tcplay: Fully featured Truecrypt implementation to open and create Truecrypt compatible hidden containers with cascade ciphers and keyfiles. This is a command line utility that works in Linux and DragonflyBSD, you can add a front end graphical interface with zulucrypt or Luksus.

Luksus: A terminal program for Linux and BSD that lets you encrypt and decrypt data using Geli, LUKS, GnuPG or Truecrypt. A wrapper around tcplayGeli and cryptsetup, with a front end graphical interface for those who find the command line too difficult.

Luksus encryption front end
Luksus encryption front end

RealCrypt: An open source forked version of Truecrypt for Fedora Linux, it comes as a RPM package and it can be easily installed in Fedora using the repositories. It has a graphical interface and the same capabilities that Truecrypt has, with a different name and logo as requested by Truecrypt licensing terms. There are no significant code differences in between them.

Encrypted Data Storage (EDS): Android app that can create and open any Truecrypt container but there is no on the fly mode and data will be decrypted to a temporary file, this could be a security risk if you believe that your smartphone can be stolen as temporary data written to solid state disks is recoverable with forensic tools.

EDS Android Truecrypt
EDS Android Truecrypt

TruPax: A Java based program that can open and create Truecrypt compatible encrypted containers. I will work on any operating system that has Java installed, Windows, Mac OS, BSD and Linux. It can be used with a graphical interface or in command line mode to automate tasks.The software is open source, portable and it was coded independently from Truecrypt.

Truecrypt compatible software TruPax
Truecrypt compatible software TruPax

Cryptonite: Open source app that brings EncFS and Truecrypt to your Android phone, the program is still in development and intended for advanced users. Cryptonite can decrypt any Truecrypt container using your smartphone. If you want to run Android in your desktop, there is an open source project that has ported it to PCs and can be installed as if it was a Linux distribution. This will give you a bigger screen when decrypting data.

 

http://www.hacker10.com/tag/truecrypt-alternative/

Largest DDoS Attack Hit Hong Kong Democracy Voting Website

largest ddos attack tool
Hackers and cyber attacks are getting evil and worst nightmare for companies day-by-day. Just last week a group of hackers ruined the code-hosting and software collaboration platform, ‘Code Spaces’ by destroying their Amazon cloud server, complete data and its backup files too.
 
Recently, the largest ever and most severe Distributed Denial of Service (DDoS) attacks in the history of the Internet has been recorded that hit the online democracy poll promoting opinion on the upcoming Hong Kong elections.
 
PopVote, an online mock election operated by The University of Hong Kong’s Public Opinion Program, by Saturday recorded more than half a million votes in less than 30 hours in the unofficial referendum that provided permanent residents of Hong Kong to choose their preferred political representatives, that is suppose to be continued until June 29.
 

However, the Chief Executive is officially chosen by a 1,200-member Election Committee under the current political system and drawn largely from pro-Beijing and business camps.
 
On the first day of voting, China’s State Council denounced the voting as “illegal and invalid.” Hong Kong’s chief executive, Leung Chun-ying, said all the proposals on the ballot are not complied with Hong Kong’s Basic Law, the territory’s de facto constitution.
 
On Friday, Matthew Prince, the CEO and co-founder of San Francisco based CloudFlare, the web performance company maintaining the voting website, said that the DDoS attack on the Occupy Central’s voting platform was “one of the largest and most persistent” ever.
 
According to Prince, the cybercriminals appeared to be using a network of compromised computers around the world to effectively disable the service of the voting website with an overwhelming amount of traffic. In such cases of attacks, the computer users who are exploited are usually unaware that their systems have been compromised.
 
Prince also wrote on Twitter: “Battling 300Gbps+ attack right now,” on the first day that the vote began. Three hundred gigabits per second is an enormous amount of data to take down any huge servers.
 
Also a DDoS attack last year on Spamhaus, a non-profit organisation that aims to help email providers filter out spams and other unwanted contents, is largely considered to be the biggest DDoS attack in the history, which the Cloudflare said the attack “almost broke the Internet.”
 

Millions of LinkedIn Users at Risk of Man-in-the-Middle Attack

Linkedin mitm

Two year back in 2012, one of the most popular online social networking sites Linkedin spent between $500,000 and $1 million on forensic work after millions of its users’ account passwords were compromised in a major security data breach. But, it seems that the company hasn’t learned any lesson from it.

WHAT IS MAN-IN-THE-MIDDLE (MitM) ATTACK
Before moving on to the story, let us discuss some emerging and common threats against the social networking sites nowadays. If we talk about less publicized but more danger, then Man-in-the-Middle (MitM) attack is the most common one. By attempting MitM attack, a potential attacker could intercept users’ internet communication, steal sensitive information and even hijack sessions.
Though MitM attacks are popular and have existed for years, a major categories of today’s largest websites and social networking sites still haven’t taken the necessary steps to safeguard their users’ personal and sensitive data from the vulnerabilities that raise the danger of this type of attacks.
LINKEDIN SSL STRIP ATTACK
The popular professional network, LinkedIn has left hundreds of millions of its users exposed to Man-in-the-Middle (MitM) attack due to the way the site uses Secure Sockets Layer (SSL) encryption in its network.
No doubt, LinkedIn is using HTTPS connection for user login pages, but they are not using HTTP Strict Transport Security (HSTS) technology that prevents any communications from being sent over HTTP, instead send all communications over HTTPS.

Linkedin mitm hack

According to researchers at Israel-based Zimperium Mobile Threat Defence, the poor implementation of HTTPS/SSL allows a hacker to intercept a user’s communication by replacing all “HTTPS” requests with its non-encrypted form, “HTTP”, known as “SSL stripping” attack.

Once the attacker has extracted a user’s credentials, they can reuse the user’s credentials or session cookies to authenticate and forge the exact session,” reads the blog post.

VIDEO DEMONSTRATION
In a video demonstration, researchers have practically used this tool against LinkedIn website and as a result of SSL stripping, they intercepted one of its users’ account by a MITM attack and successfully grabbed users’ account information and every single user they tested was vulnerable to this attack.
VULNERABLE COMPONENTS
By attempting MitM attack against the website, an attacker can grab a LinkedIn user’s credentials, hijack their session to gain access to all other LinkedIn information and impersonate the user. Attackers could do multiple things including:
  • Email address
  • Password
  • Read and Sent Messages
  • Connections
  • “Who viewed my profile”
Attackers can impersonate the user to use any account feature, including:
  • Send invitations to connect
  • Edit the user’s profile
  • Edit job postings
  • Manage company pages
So not only is your personal LinkedIn information at risk, but also if you are an administrator for your corporate LinkedIn presence, your company’s brand reputation could also be damaged if a malicious actor were to gain control over posts and email communication on LinkedIn,” reads the blog post.
REMOTE ATTACKS
Moreover, this vulnerability in the LinkedIn doesn’t just exist when a potential attacker is on the same network as the targeted victim.
To perform MITM attack remotely, an attacker can compromise a device and once that device enters a different network, the same attacker can use the victim’s device remotely to perform man-in-the-middle attack on other users on the victim’s network.
LINKEDIN IMPLEMENTING HTTPS BY DEFAULT, BUT VERY SLOWLY
Researchers from Zimperium first responsibly reported this critical ‘session hijacking’ vulnerability to the LinkedIn security team in May 2013. Despite, reaching out to LinkedIn six times over the last year, the team have not responded seriously.
Later from December 2013, LinkedIn started transition of the website to default HTTPS and just last week they have successfully upgraded US and European users to Default HTTPS Network. Because of slow implementation of default SSL, Zimperium finally rolled out the disclosure of the vulnerability publically.

LinkedIn spokeswoman Nicole Leverich said the issue described by Zimperium “does not impact the vast majority of LinkedIn members given our ongoing global release of https by default.

HOW TO ENABLE FULL HTTPS MANUALLY
However, In 2012, LinkedIn offers its users an option to change their security settings to full HTTPS manually, but many might not have known about it. You can enable it by going into your LinkedIn settings, Open “account” tab and Click “manage security settings” to select Full HTTPS.

Up ↑