Store passwords the right way in your application
I suspect most of our readers know this, but it can't hurt to repeat this every so often as there is a lot of confusion on the issue. One thing that gets to me is seeing reports of website compromises that claim "the passwords were hashed with SHA-256". Well at face value that means 90% of the passwords were decoded before the news hit.
If you have an application that's protected by passwords, there are a few rules to follow:
Rule #1: Never store plain passwords, use a hash
The worst case solution is that passwords are stored as is. Any attacker breaking in to the application now has everything they need to impersonate any user in your application. But typically they have much more: your users typically reuse passwords, so there's no telling to how far this goes. And if the application is e.g. a webmail solution: well all accounts that can be reset by sending an email here are now essentially broken as well.
A hash function is a one-way function: it converts input to output but there is no easy way to reverse the process. There's a whole bunch of algorithms commonly used.
The goal/advantage here is that even if the attacker takes away the user tables, he's still got some work to do.
Unfortunately the work is doable so we need more ...
Rule #2: Use a salt
Attackers can pre-compute (or buy) so called rainbow tables: it's a list of pre-computed password -> hash values and as such decoding any common password is as fast as a lookup to them gets.
A salt is essentially a random string chosen at the time of password change or creation and stored along with the hash and concatenated to the password. This makes rainbow tables useless.
But it's still not enough...
Rule #3: Use a slow hash function
This rule is most often forgotten, yet it is so critical.
The most common hash functions we use daily (e.g. SHA-256) are designed to be fast. But for storing passwords that's going to work against us big time.
Even the attacker can't break SHA-512 in a brute force fashion, even if they can't use rainbow tables due to salts being used, they still will find the vast majority of the passwords our users can remember in a manner of minutes to hours if you use a fast hash.
So you need to use a slow hash function.
Since there's a Rule #0 in all things crypto: Don't invent your own: Just use the appropriate functions already there. Many of these slow hash functions allow one to chose the cost. If so, set it as high as you can bear with your current hardware.
Examples
In PHP one can use the crypt function using blowfish or many thousands of rounds of SHA-256 or SHA-512 instead of a simple hash function.
Or even better if the cryptographic password hashing extension is installed, use it as it has simple support for e.g. rehashing passwords to update the strength of a hash of a stored password upon login of the user.
Or even better if the cryptographic password hashing extension is installed, use it as it has simple support for e.g. rehashing passwords to update the strength of a hash of a stored password upon login of the user.
Feel free to add comments on how to do it in other languages.
--
Swa Frantzen -- Section 66
Adobe June 2013 Black Tuesday Overview
Adobe released their June 2013 Black Tueday bulletins:
| # | Affected | CVE | Adobe rating |
|---|---|---|---|
| APSB13-16 | Flash Player & AIR | CVE-2013-3343 | Critical |
--
Swa Frantzen -- Section 66
vmware security advisory VMSA-2013-0008
VMware joined the Black Tuesday frenzy with a release of a security bulletin VMSA-2013-008. It covers CVE-2013-3520, a vulnerability in handling file uploads in the vCenter Chargeback Manager that allows remote code execution.
--
Swa Frantzen -- Section 66
Other Microsoft Black Tuesday News
Microsoft Security Advisory 2854544 was released today. It adds functionality to manage and use Cetificate Trutst Lists.
Microsoft released a few days ago a fixit to allow one to control the availability of the java plug in in MSIE.
--
Swa Frantzen -- Section 66
Microsoft June 2013 Black Tuesday Overview
Overview of the June 2013 Microsoft patches and their status.
| # | Affected | Contra Indications - KB | Known Exploits | Microsoft rating(**) | ISC rating(*) | |
|---|---|---|---|---|---|---|
| clients | servers | |||||
| MS13-047 | The usual monthly MSIE cumulative patch, adding fixes for a bunch more vulnerabilities. All but one are memory corruption vulnerabilities. The odd one is an information leak. | |||||
|
MSIE CVE-2013-3110 CVE-2013-3111 CVE-2013-3112 CVE-2013-3113 CVE-2013-3114 CVE-2013-3116 CVE-2013-3117 CVE-2013-3118 CVE-2013-3119 CVE-2013-3120 CVE-2013-3121 CVE-2013-3122 CVE-2013-3123 CVE-2013-3124 CVE-2013-3125 CVE-2013-3139 CVE-2013-3141 CVE-2013-3142 |
KB 2838727 | No publicly known exploits |
Severity:Critical Exploitability:1 |
Critical | Important | |
| MS13-048 | A kernel memory information leak vulnerability. | |||||
|
kernel CVE-2013-3136 |
KB 2839229 | No publicly known exploits |
Severity:Important Exploitability:3 |
Important | Less urgent | |
| MS13-049 | A vulnerability in the implementation of TCP/IP allows for a TCP connection to cause the system to stop responding. | |||||
|
TCP/IP CVE-2013-3138 |
KB 2845690 | No publicly known exploits. |
Severity:Important Exploitability:3 |
Important | Critical | |
| MS13-050 | Privilege excalation vulnerability when deleting a printer connection. | |||||
|
Print spooler CVE-2013-3139 |
KB 2839894 | No publicly known exploits |
Severity:Important Exploitability:1 |
Important | Important | |
| MS13-051 |
A memory corruption vulnerability allows random code execution in the context of the current user due to failure to properly handle PNG images. Note it also affects Office for Mac 2011. |
|||||
|
Office CVE-2013-1331 |
KB 2839571 | Microsoft claim this is being exploited in "targeted attacks". |
Severity:Important Exploitability:1 |
Critical | Important | |
We will update issues on this page for about a week or so as they evolve.
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY
We appreciate updates
US based customers can call Microsoft for free patch related support on 1-866-PCSAFETY
(*): ISC rating
-
We use 4 levels:
- PATCH NOW: Typically used where we see immediate danger of exploitation. Typical environments will want to deploy these patches ASAP. Workarounds are typically not accepted by users or are not possible. This rating is often used when typical deployments make it vulnerable and exploits are being used or easy to obtain or make.
- Critical: Anything that needs little to become "interesting" for the dark side. Best approach is to test and deploy ASAP. Workarounds can give more time to test.
- Important: Things where more testing and other measures can help.
- Less Urgent: Typically we expect the impact if left unpatched to be not that big a deal in the short term. Do not forget them however.
- The difference between the client and server rating is based on how you use the affected machine. We take into account the typical client and server deployment in the usage of the machine and the common measures people typically have in place already. Measures we presume are simple best practices for servers such as not using outlook, MSIE, word etc. to do traditional office or leisure work.
- The rating is not a risk analysis as such. It is a rating of importance of the vulnerability and the perceived or even predicted threat for affected systems. The rating does not account for the number of affected systems there are. It is for an affected system in a typical worst-case role.
- Only the organization itself is in a position to do a full risk analysis involving the presence (or lack of) affected systems, the actually implemented measures, the impact on their operation and the value of the assets involved.
- All patches released by a vendor are important enough to have a close look if you use the affected systems. There is little incentive for vendors to publicize patches that do not have some form of risk to them.
(**): The exploitability rating we show is the worst of them all due to the too large number of ratings Microsoft assigns to some of the patches.
--
Swa Frantzen -- Section 66
ISC StormCast for Tuesday, June 11th 2013 http://isc.sans.edu/podcastdetail.html?id=3359
×
![modal content]()
Diary Archives
Comments
www
Nov 17th 2022
4 months ago
EEW
Nov 17th 2022
4 months ago
qwq
Nov 17th 2022
4 months ago
mashood
Nov 17th 2022
4 months ago
isc.sans.edu
Nov 23rd 2022
3 months ago
isc.sans.edu
Nov 23rd 2022
3 months ago
isc.sans.edu
Dec 3rd 2022
3 months ago
isc.sans.edu
Dec 3rd 2022
3 months ago
<a hreaf="https://technolytical.com/">the social network</a> is described as follows because they respect your privacy and keep your data secure. The social networks are not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go.
<a hreaf="https://technolytical.com/">the social network</a> is not interested in collecting data about you. They don't care about what you're doing, or what you like. They don't want to know who you talk to, or where you go. The social networks only collect the minimum amount of information required for the service that they provide. Your personal information is kept private, and is never shared with other companies without your permission
isc.sans.edu
Dec 26th 2022
2 months ago
isc.sans.edu
Dec 26th 2022
2 months ago