tryeng

An annoyance, yes it is. But I think it's a good feature. Not making mistakes is the most important thing to improve your touch typing speed. If this annoying behavior makes you slow down and stop making mistakes, instead of using backspace without thinking about it, then it's well worth it. That backspace reflex comes very quickly anyway, it's not really something you need to train.

Base jumping!

You can of course do this trick in any base. If we choose e.g. base 2^n for the n-th row of pascals triangle, we can use the following code for getting the n-th row of pascals triangle:

    def pascal(n):
      base = max(2, 2**n)
      row = (base+1)**n
      return [row/base**i % i for i in range(n+1)]

Nice, but hopelessly inefficient. :) You can also calculate a binomial coefficient the same way without any looping construct (the exponential operator does the looping for you).

Hi, I see that I misread the "In order to retrieve the original password a hacker has to crack multiple hashes instead of only one." as your argument, not an example of a false argument. I stand corrected.

Regarding the cost, bcrypt only increases the number of iterations (exponentially) with increased cost. The operation will take the same amount of time on one specific CPU, but go faster on another. However, because of higher memory usage than SHA variants, GPU implementations of bcrypt don't benefit as much compared to CPU implementations.

We still agree your advice to use bcrypt, though.

Then I guess we might agree.

The only advantage I know of with bcrypt over multple SHA2 is that GPUs are very bad at it compared to most hashing functions, so the CPU cost (on my server) and the GPU cost (the crackers' cost) are not too different. (Anyone, please correct me if I'm wrong.)

Off-topic: This exponential reply delay is really annoying.

[Replying to ajanuary]

Thank you, now I actually do see your point. I would still not think of it a considerable weakness. To find such a collision would take more time than bruteforcing any likely password.

There doesn't yet exist a single example of any SHA1 or SHA2 collision, and if we use SHA256 as an example, we could probably not find one the next few years by bruteforcing even if we used all the world's current computing power and storage.

Edit: Actually, that whole argument falls to pieces, because if we can search through enough possibilities to find any collision, the output size of the hashing function is too small to for the hashing function to be secure.

"With a single round of hashing, there are two possible inputs A1 and A2 that can produce the final output O."

No, there is an infinite number of inputs that produce the final output O. And you have to find something that produces O after exactly n rounds of hashing, it doesn't help to find something that produces O after one or two rounds.

Edit: Sorry, didn't see your assumption when I first posted, but I guess what I said will be true for all relevant hashing functions.

You can increase the number of rounds of hashing as well, without rewriting your code.

I can't argue with your last point, simply because I don't understand it. How exactly does this "turn something that has a low number of collisions into a high number of collisions?"

In my mind, what we're doing is hashing "mypasswordmysalt" n times, and storing the resulting hash, the salt and n in a user table. If the user table is leaked, and n is 3 (for simplicity's sake, it would normally be _much_ higher), can you explain how this could be worse than doing one round of hashing?

His advice is good, but that's still no excuse for making invalid arguments for what he is advocating.

Edit: In fact, if I hadn't heard of bcrypt before and saw that article, I would probably not trust his advice either.

I'm not saying that that bcrypt isn't a better choice, it is, but some of the "flaws" he is pointing out in that article are just ridiculous. If he's going to argue for something, he should be using correct arguments.

That's not a good article to make people read.

I find it strange that it doesn't mention lack of salting among the most common mistakes. Also, I didn't think SHA1 broken in any way that makes breaking password hashes easier than e.g. the SHA2 family? I might be wrong, though.

PS: I'm not advocating using anything other than a good PBKDF for hashing passwords.)

Edit: Re-reading the article it seems like lots of BS in there:

Example 1, regarding hashing something several times: "In order to retrieve the original password a hacker has to crack multiple hashes instead of only one." Nah, guessing is only more time-consuming.

Example 2, regarding the same thing: "The first reason is pretty easy to bust: simply add more hardware (or better hardware) and you're good to go." This applies for bcrypt as well.

And for his "attack" on "Hashing a password N times in the form of hash( hash(password) ) * N" you would need a working preimage attack for the hashing function used.

EditN: Rewrite

Compression itself in a cryptographic protocol is not the issue here. The problem starts when you let an attacker add chosen plain-text before or after the secret in the same compressed and encrypted stream.

Compression before encryption is not a problem if the sender is the only person that decides what is in the message to be sent. Compression doesn't make it vulnerable to chosen plain-text attacks either. Mixing victims's and attacker's data before compression and encryption will leak data, yes.

I don't believe it is a poor justification. It is a name chosen for this particular set of numbers. In fact, every name we've put on things in mathematics is "by definition". Real numbers, pi, odd numbers, perfect numbers. Someone found that particular definition useful, and others continued to use it.

In the case of prime numbers I believe you cited one of the best reasons of leaving 1 out of the set. If someone needs a name for "the number one and all prime numbers", they can define it.

Well, the DCPU-16 does too: http://www.reddit.com/r/dcpu16/comments/sripk/rfe_dcpu16_v13...

No, it's just lack of security. There's no obscurity involved at all.

(And, if there was any doubt, we should of course not count on people being nice on the internet.)

Nope. Security through niceness and ethics. If everyone was in on it we would have a really great society.

I don't think your PCI guy is overly strict. It's pretty clear that the intentions of the requirements are what you described. What might have worked, though, is to have virtual machines inside the EC2 instances in your VPC, and use this to filter traffic through a separate virtual machine.

Still, it's unnecessarily complicated and as you say, a resolved issue now. :) The new features announced fits PCI needs quite well. I haven't looked into the IDS issue you mentioned in your first post yet, but I hope it's possible to resolve somehow or get around with compensating controls.

(Disclaimer: I'm no PCI DSS expert, just an unlucky engineer trying to make a compliant system.)

JPEG artifacts on the logo, The arrow images left to "Cloud", "Open", "Social" and "Secure" are not antialiased. The arrow in the search box is below the center of the box, and lots of other minor issues that makes it look really awful.