Password Hashing for Developers

I loved this blog by “No Bugs” Hare about Password Hashing and thought it's a great read for developers. Read it and enjoy! Here are some of the main highlights I took away ...

- What is hashing? It's a one-way transformation. It's NOT encryption. You cannot decrypt a hashed password if done correctly.
- Why do it? If an attacker gains access to your password table, you want to prevent him from gaining access to all user passwords.
- Can hashing be done wrong? If it's simple hashing, an attacker can create a dictionary of all possible passwords (or at least the most common) and do a lookup to see if any of your users have those passwords.
- What is salt? If my password is 'abc' and so is yours, salt will make the hash different. Thus dictionaries aren't helpful now because the password 'abc' can become many different hashes.
- Can a salted hashed database be cracked? Yes, if an attacker gets your database and has all your hashes and salts, he can take it to his lab and still try to guess every possibility for that salt.
- What makes offline cracking harder? There are 2 answers mathematically speaking. Long passwords. Slow hash functions. The amount of time to do an offline brute force increases based on those factors.


Also, don't forget that even if you properly hash and salt your password database, an attacker can get a password from other methods. Make sure passwords are passed over encrypted protocols (like HTTPS) at all times so they can't be sniffed out. Implement a strong password recovery solution so that an attacker can't just reset or recover a password. Implement employee training to educate them against phishing and credential harvesting attacks.

And of course you've heard that passwords may not be the way of the future. A better solution is perhaps something like 2-Factor authentication that requires 2 things to login such as a password & a token from your iphone.

More about neonprimetime

• neonprimetime pastebin
• neonprimetime virustotal
• @neonprimetime twitter
• neonprimetime reddit

Top Blogs of all-time

1. pagerank botnet sql injection walk-thru
2. DOM XSS 101 Walk-Through
3. php injection ali.txt walk-thru

Top Github Contributions

1. Qualys Scantronitor 2.0

Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.

Web Developers, You Can Help Prevent Password Dumps

A recent Arstechnica article told a story of 13 million plaintext passwords being dumped.. It stated

"...a code routine that placed a user's plaintext password in the resulting URL. That means the unobfuscated passwords were likely written to all kinds of administer logs...

This got me thinking of some red flags that you, as a web developer, should raise if you ever see happening. Some of these red flags could also apply to any regression tester, system administrator, or security analyst if they happened to come across it also. When I say "raise a red flag", I mean that you should open a bug ticket, report it to your Senior developer/Manager, or document it in your risk register. The things on this list are the exact type of things that could lead to your company being the next big breach in the news...

When to Raise a Red Flag

- If you see a plaintext password in a URL (Why? urls get logged everywhere)
- If you see a plaintext password in a hidden html field (Why? these aren't truly hidden)
- If you see a plaintext password in a Cookie (Why? cookies are stored locally unencrypted on the harddrive)
- If you see a plaintext password in the html of an unencrypted protocol like HTTP(Why? it can be sniffed and viewed in plaintext)
- If you see a plaintext password in your syslogs(Why? syslogs are generally sent in unencrypted udp packets)
- If you see a plaintext password in the Windows Events Viewer (Why? log files are not encrypted)
- If you see a plaintext password in any Database table, including log/error tables (Why? sql injection is your worst nightmare)
- If you see a plaintext password in a configuration or flat file (Why? if somebody opens it up, or a backup, they have the file)
- If you see a plaintext password in Source Control like TFS, Github, etc. (Why? developers shouldn't see passwords, just admins)
- If you see a plaintext password in scripts (bat files, powershell, python, etc.) (Why? whomever opens the script has the password)
- If you see a plaintext password in an Error or Application Log (Why? log files are not encrypted)
- If you see a plaintext password in an excel spreadsheet (Why? excel does not replace proper password management tools)
- If you see a plaintext password in a database procedure/function (Why? database code is not encrypted)
- If you see a plaintext password in your website code (Why? web code is not encrypted & is saved to source control)


Passwords, whether you like it or not, are critical to protecting your kingdom. Some of the scenarios listed above could lead to an attacker gaining access to customer passwords. Some of the scenarios listed above could lead to an attacker getting full administrative access to your systems and network. Apply least privilege. The only passwords developers should ever see are ones for their test environment. Developers should never have to know Production passwords. And passwords should never be stored in any location or unencrypted format where developers could even stumble across them. Thus if you are a web developer and you come across any of the scenarios above, don't take it lightly. Let somebody know, and work towards finding a method to mitigate the risk.

Copyright © 2015, this post cannot be reproduced or retransmitted in any form without reference to the original post.