Related
Regardless of the language I'm always puzzled by the concept of security through an if. All the code I write relies on success of that one line with if statement:
user = getUserName();
password = getPassword();
if (match(user, password)) {
print secret information;
}
Since it's only one line I feel like sabotage can be relatively simple. Am I overlooking things, or is a single if really the best way to do this?
You are right, an if like this is easily hacked. If one reverse engineers this application, you can easily modify a few instructions to skip the if.
There are various options, like obfuscating the executable or adding more complex checks and in add them in various places in your application. But whatever you do, your application can always be hacked.
Best thing is not to worry about it. By the time your application is so good and great and widely used that people are actually willing to put effort in cracking it, you will probably make enough money to protect it better. Until then, it's a waste of time to even think about it.
In the specific case you are showing, if you were really worried about unauthorized people seeing the secret information output by "print secret information;" you would encrypt the "secret information" with the supplied password. This would ensure that only the person who was able to provide the proper password would be able to see the secret information.
There's one thing about IF's that is often overlooked. It's called timing attack. Suppose you have a web application that does comparison based on direct matching of password sent against password stored in the DB (yes, I know that nobody in his mind will store passwords in the DB, but as Cheshire Cat said, "we are all mad here"). Then comparison procedure takes different time depending on whether the passwords don't match on the first character, on the second one or on the last one. While it might seem that the time difference is tiny, it's enough for attacker to attempt to guess the password even across internet, not talking about local analysis. Timing attack is a bit more complicated, than I described, but in general IF comparison is not 100% safe, at least not in all cases.
The if statement is absolutely secure, and can never be the cause of a vulnerability. Vulnerabilities arise from nearly everything else in your code.
It is possible that the comparison operator that you are using is flawed. For instance the == operator employs fuzzing matching where a range of possible values are accepted. This might not be good for secuirty but its hard to come up with a good example, it doesn't really matter for a password. A simple $password==$_GET['password'] should work just fine.
Your if statement could also be relying on bad regular expression such as
if(preg_match('/(.+)\\.js/'.$_GET['file'])){
readfile($_GET['file']);
}
In this case the regex is looking for a .js anywhere in the string, not enforcing it to be at the end.
?file=../../.js/../../../../../../../etc/passwd
(And this vulnerability won me $3,000 in the Mozilla bug bounty program ;)
If this is a server code - this is not a problem, as long as you keep your server secure.
If this is a client code - you are right. Someone can manipulate your code - either the binary file or the memory image (once loaded). However, this is true for any client application. You can only make it harder (by using tools like PECompact + Anti-debug plugin for example), but you can't achieve very strong security.
I'm not sure to understand your question.
Software security techniques are imperfect, and AFAIK they pre-suppose few bugs in the compiler, and a "perfect" hardware (that is, the processor is interpreting correctly the machine code).
I am not familiar (but interested) with approaches for imperfect hardware (except of course by using redundancy or other techniques, e.g. ECC, to detect hardware errors).
There is nothing insecure about one line with an if in it.
If the code is running on your server, what matters is how secure that server is. If an hacker gains access to it, it doesn't matter how complicated your code is, he will be able to circumvent it.
Similarly, if your code runs on the computer of a potential attacker (like a computer game that you want to protect), there is nothing you can do to stop the attacker. You can make his work slightly more difficult, but that's all.
You shouldn't worry about the security of one line, but of the system as a whole. If you make your code more complicated, all you did is introduce more potential for bugs. Using more complicated code is an attempt at security through obscurity, which doesn't work.
If you can't trust your computer to execute a simple if correctly, you can't trust it at all.
I'm bringing this up after spending a few hours trawling through a number of posts on SO with regards to the most secure way to handle passwords in PHP/MySQL. Most answers seem to be fairly out of date, as are links that people are directed to. Many recommend md5 and sha-1.
We all know that MD5 and SHA-1 are no longer worth using due to the fact that they have been reversed, and also because there are a number of databases out there that have built up millions of md5/sha1 strings. Now, obviously you get around this with salt, which I intend to do.
I have however recently started playing around with whirlpool, which seems much more secure, and up to date. Would I be right in thinking whirlpool+salt is ample protection for passwords?
I was actually considering something like this:
<?php
$static_salt = 'some_static_salt_string_hard_coded';
$password = 'some_password_here';
$salt = 'unique_salt_generated_here';
$encoded = hash('whirlpool', $static_salt.$password.$salt);
?>
What do you think? Overkill or sensible?
This is probably good enough for most applications.
However, salts become (almost) useless if your DB is leaked -- including the static one if your configuration file is leaked too. They are a good protection against rainbow tables, but nowadays it's easier to use a bunch of GPUs to brute-force a given hash.
IMHO, currently the best solution is to use bcrypt. It's apparently supported in PHP 5.3+, and here's an example of how to use it.
This will be enough (however, there is no sense in static hardcoded salt). And, why not to use SHA256? Whirlpool is rarely used.
It's particularly meaningless to discuss the merits of particular algorithms without a much wider consideration of the threat models and specifics of implementations.
Yes, whirlpool does appear to have some advantages in terms of how effective it is as a hash, but as Nickolay says that may be deceptive and due to the fact it is less widely used. But there are other considerations too - for some purposes storing a 128 character string for each account may be an unnecessary overhead. For everyone it's a question of what the software supports (and some people might want to use the same account record to control access to different systems).
At the end of the day, it doesn't matter how sophisticated your hashing algorithm is:
given a free choice, users pick bad, guessable passwords
users will use the same password for different services
If it works for you - then great - but there is no universal solution.
I am a bit of a newbie around Security nitty gritties and especially around Cryptography.
In the application we are building(ASP.net application built on .NET 3.5), we are currently using Databases to save our users authentication information (AD etc is not an option at this point).
The intention is to do a one way salted hash of the passwords using SHA256Managed on user creation and then validate the users using the same.
Ideally, we do not want to use any third party dll's for the hashing algorithm unless absolutely necessary to avoid any unnecessary dependencies.
Questions:-
1. Is there a better option than doing a salted one way hash?
2. Is SHA256 a reasonably reliable / secure option or should we be considering anything else?
3. Is the SHA256Managed implementation in System.Cryptography good enough in terms of it speed etc or should we be considering 3rd party alternatives to it?
Any pointers as to the approach / implementation will be helpful.
I did some research on this back in the day, and the consensus was BCrypt was one of the best ways to do a one way hash.
You can see a C# implementation here: http://derekslager.com/blog/posts/2007/10/bcrypt-dotnet-strong-password-hashing-for-dotnet-and-mono.ashx
In addition, what's nice about BCrypt is you can decide how many rounds you'd like it to go through.
So, you can make it take about 1 second to encrypt for example. For a user, that's an acceptable wait time, but for someone trying to attack you through brute force, 1 second is an eternity.
I am no security expert, so take what I say here as a grain of salt. A salt you can send in to your BCrypt method :)
In addition, here's some advice from Atwood on this: http://www.codinghorror.com/blog/2007/09/youre-probably-storing-passwords-incorrectly.html
Update:
Since answering this, NuGet has made using BCrypt much easier: http://nuget.org/packages?q=bcrypt
I can't vouch for any particular implementation there, so take a look at the code, but this should make using and integrating BCrypt much easier.
Yes, retina scan (just kidding). Storing passwords as hashes with salt is the correct way.
SHA256 is good. Obviously I don't know the type of an application you are working on, but SHA256 is good for the vast majority of projects. You can always go to a higher key length (384, 512) if required. Consult with your security architect.
SHA256Managed (we are talking .net, right?) is good. We use it in our projects.
Please also consider reading this:
http://www.obviex.com/samples/hash.aspx
Yes, there's nothing wrong with SHA256 and certainly SHA256Managed will be "fast enough" for most use cases (I'm sure you're not expecting to be validating 1000s of login requests per second, and even if you were, the rest of the site would still be dwarfing the login requests...)
But have you considered the Membership stuff that's built-in to the framework? They're already done all the hard work in terms of securely storing credentials, and implementing all the support functionality as well (such as password resets, etc)
Storing password hashes with salt it correct. However, it's easy to get even that much wrong. Sure, right now SHA256 will keep the baddies at bay, but give it a few years. Suddenly, SHA256 might not seem so secure anymore. You need to use BCrypt, a future-proof hashing algorithm.
Problem with doing just one pass of SHA256 is it is too fast and one with great hardware can generate rainbow tables for lots of salts easily...to get around this you need to perform key stretching....kI'm not going to give you a lesson on key stretching but the bcrypt implementation that people talk about performs key stretching. If you want a more modern alternative to bcrypt which uses HMACSHA256 or 512 in .NET, I recomend this API:
https://sourceforge.net/projects/pwdtknet/
I created a nice long passphrase, used it a few times, then forgot it ;) The twist is, I know the general theme and probably almost all of the characters. The perfectionist in me doesn't want to revoke the key or anything like that (and I think I need the passphrase to revoke it anyway, right?). I feel I should be able to have a good go at this by brute-forcing the likely layouts/characters that I've got wrong/mis-typed. I wrote a C program to produce such combinations. Unfortunately I don't have the code to hand (I'll go with the "it's not relevant" excuse for now ;). I also came across some code on the web using GPGME to do exactly this as a proof-of-concept. It had the comment "this could easily be 100 times faster". Problem is, profiling the code shows the bottleneck to be the GPGME call itself. Is this expected, or is it a limitation of GPGME that could be solved using the full library or a dedicated implementation?
How would you go about doing this? Obviously this method is infeasible for any decent unknown passphrase, but I think the key is that I know what I typed without knowing the exact formatting of how I typed it - should be feasible, no?
(and I think I need the passphrase to revoke it anyway, right?)
No, you need the revocation key. Which you should have generated and printed out when you created your key. Then stored it in a safe place, not where someone could use it to revoke your key when you don't want them to.
I've tried to brute-force passwords that I almost remembered, but without success. There are still a lot of permutations, and it takes a lot of rules on what can come after what to narrow it down to a reasonable problem size. I never tried too hard on this, since I luckily have never forgotten my GPG passphrase. Mostly when I've forgotten a password it's a login to a remote machine at the university, and I've never wanted to hammer on the ssh port, or webmail, with my guesses.
Maybe the function you're calling does a lot of setup that is non-key-dependent? So you could speed it up by copying the code out of the library and putting your brute-force loop later on in it.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Pros:
I can't remember "good" passwords anyway so remembering them is not an issue.
they don't look like passwords
they are darn near impossible to guess (128 bits of entropy)
easy to generate (offloads the "good PRNG" problem)
Cons:
???
In particular; what about for passwords that computers enter like for databases logins on some setups.
One major con is that you don't necessarily have "128 bits of entropy" as stated in the original question.
Many GUID Algorithms have information embedded in them in predictable patterns, for example the MAC address of the computer, the date/time, or an incrementing sequence. Cryptanalysis of the WinAPI GUID has shown given the initial state one can predict up to next 250,000 GUIDs returned by the function UuidCreate
For example, I have about a 50% chance of guessing the first digit in the first position of the third group of digits since it will be either 1 (for V1 guids) or 4 (for V4 guids)
Source: http://en.wikipedia.org/wiki/Globally_Unique_Identifier
Cons:
You will write them down somewhere.
You will probably email them, or write them down again if you need to tell anyone else.
They may be too long for certain systems.
They're practically impossible to memorize, so you might change them more frequently then desired.
So unless they're system passwords which change rarely, I doubt they are good passwords.
Con:
It would be nearly impossible to remember a 32-byte alpha numeric string.
If you really want a secure password, consider a passphrase instead. A long passphrase is easily remembered, and very difficult to brute force.
Con:
Some systems have limits on the maximum length of passwords. If you're only using hex digits this can limit your entropy to perhaps as little as 32 bits.
Cons:
Password fields are not always long enough.
More difficult to enter - you'd probably store the password in a program, not in your head. That's a bit of a security problem...
... pros:
Nobody will be able to force your password out of you.
Big-random-number passwords have been done before. They're called OTPs, and are much more secure than what you're suggesting because they change over time, and tend to be generated by secure devices. Of course this is only relevant if you are designing a password system.
Does anyone ever need to enter it as a password? Or do you want to use it as a one-time thing? Because seriously, no one wants to enter a GUID in a passwordfield. People have trouble enough as it is, entering WEP/WPA2 wifi network keys. And most of the time, those are one-timers.
#Miyagi: that's the most obvious con ofcourse. They'll have to write it down.
Technically they would be good passwords
In real life, they would be horrible passwords
You would end up having to write down the passwords, use a password manager, or some other form to actually use the password... in a way moving the failure point from the password to another aspect.
Consider using passphrases. Sentences with substitutions for certain letters or other characters, and for numbers, typing them with the SHIFT, converting easy to remember numbers in to well defined character sequences.
For example bcs19850101bcs would be bcs!(*%)!)!bcs
If you want a secure password that you wish to leave to a password manager on a UNIX-like system, you're much better just pulling one from /dev/random and encoding it into something readable. for 128 bits of entropy you can use something simple like
head -c 16 /dev/random | openssl enc -a -e
which gives a password like 5eqIviKu4pFTqSPnYosVKg==
not unreasonably long, secure, random, suicide to try to remember.
Edit: added benefits of this method over UUID include extra security in the PRNG (/dev/random) and shorter passwords, similar shortfalls
I recently wrote code to convert the first 64 bits of a checksum into a sequence of four English words. This makes a good checksum (much easier to remember than a hex mess), but I'm not sure I'd trust it as a password. If you're protecting something secure, you should use a strong password that you memorize and don't write down. If not, then any old password will do.
I think what you actually want is a cryptographically-random number, not a GUID. GUIDs and UUIDs are not random -- as JohnFx said, they tend to incorporate discoverable values like the MAC address or current timestamp, in order to guarantee uniqueness.
Instead, you should look at whatever crypto API is available to you and find a source of high-entropy random numbers. Make sure the documentation promises the output is suitable for cryptography, not just a regular PRNG. For example, /dev/random on Unix systems is a good source. Then just unroll as many random bytes as you want.
Personally this seems a bit too hardcore. I'd rather generate strings that contain a bit less entropy per character, but are easier to type and remember. For example, there are several algorithms that combine random syllables to create pronounceable nonsense words; intersperse some digits and punctuation, and you've got a good password.
I like my passwords strong and pronouncable (try one of the sites listed here for an online demo, be sure to pick a "v2" site to get the pronounciation-guide).
Con: You can't retype it, which means you will have to copy and paste. If you have your password management program on your system, not really a problem. But if you end up on a system where you don't, just retyping the thing will be very difficult.
And then after you try a couple of times you get locked out ....
Life could get very annoying.
Even if you write it down, a good password is something you can type consistently without errors.