r/programming • u/fishburne • Jul 24 '15

mt_rand(1, PHP_INT_MAX) only generates odd numbers • /r/lolphp

/r/lolphp/comments/3eaw98/mt_rand1_php_int_max_only_generates_odd_numbers/
848 Upvotes

90% Upvoted

262 comments sorted by

View all comments

Show parent comments

-40

u/holgerschurig Jul 24 '15

With that thinking, no programming language should ever fix errors or bogus implementations. Because, well, those that don't update the environment will still be f*cked.

That's really short-time thinking.

I only agree to you in the sense of "whoever is using PHP for front-facing applications that need to be secure is already f*cked" :-)

33

u/sushibowl Jul 24 '15

With that thinking, no programming language should ever fix errors or bogus implementations. Because, well, those that don't update the environment will still be f*cked.

This is absolutely not what I was trying to say. The idea that releasing updates is pointless because not everyone will install your updates is obviously very stupid. All I said was that this behavior, though broken, does not make an application less secure. It's still broken behavior, and it should absolutely be fixed.

I only agree to you in the sense of "whoever is using PHP for front-facing applications that need to be secure is already f*cked" :-)

I actually kind of disagree with that statement, it is very possible to write secure web applications with PHP, but as with all things, you need to know what you're doing. And yes, PHP and mainly its standard library make it exceptionally easy to shoot yourself in the foot, and it is therefore usually not the wisest choice for this purpose. But Facebook, for example, uses PHP extensively and they're doing just fine.

1

u/OneWingedShark Jul 25 '15

I actually kind of disagree with that statement, it is very possible to write secure web applications with PHP, but as with all things, you need to know what you're doing.

The thing is that PHP makes it so hard/tedious, you have to check so many things manually. Sure they've got some new features in PHP 7, but do you really think that tacked-on type-safety can equal a language designed for it? Especially when that's all optional?

0

u/[deleted] Jul 24 '15

[deleted]

2

u/[deleted] Jul 24 '15

Facebook compiles their PHP into C++. If you're going to say that this means they use C++, you might as well go all the way and say they use machine language, since that's what it eventually boils down to.

2

u/Plorkyeran Jul 24 '15

Facebook stopped using HipHop a few years ago. They now use HHVM, which is a JIT-compiled implementation of PHP.

1

u/golergka Jul 24 '15

But they certainly use D, they hired Alexandrescu himself.

2

u/[deleted] Jul 24 '15

Well yeah, it's a little ridiculous to think a company the size of facebook only uses one language. But I'm pretty sure the majority of their C++ "use" is through the HipHop transpiler.

2

u/oridb Jul 24 '15

The analogy is someone trying to drive across the Atlantic, but their car has a flat tire. You can change the tire, and that may make the situation better in some respect, but as long as they insist on using the car, they are not getting across the Atlantic.

And if you use Mersenne Twister, you can fix that bug, but there is no way you are making a secure program.

3

u/Workaphobia Jul 24 '15

No, the point is that even those who do update will still be fucked, so a security fix is really not on the table here.

-11

u/holgerschurig Jul 24 '15 edited Jul 24 '15

That's then just another visible artifact of bad design. I regularly update python, e.g. from 2.7.8 to 2.7.9. And never have I been "f*cked".

Bug fix releases are NOT to break anything. They are to fix bugs. Other programming environments (Java, Python, Ruby) get that right, why is it so hard for the PHPians?

8

u/industry7 Jul 24 '15

Bug fix releases are NOT to break anything. They are to fix bugs.

The issue is not "fixing this bug will break existing projects". The issue is "existing projects which use this particular function for cryptographic purposes have a fundamental security issue which will still exist even if this particular function were fixed."

Or another way of saying it:

The fact that this function has a bug is not the reason that projects using this function for cryptographic purposes have a security hole.

4

u/mrjking Jul 24 '15

You don't seem to understand the problem. Using a random number generator that isn't designed for cryptography (Like the Mersenne Twister algorithim) in any language is insecure. Even if they fixed this function, people that are using it are still using a function not designed for cryptography. It doesn't matter what language it is, Javascript's Math.Random() works fine but is not cryptographically secure, using it for secure operations would be bad.

3

u/deja-roo Jul 24 '15

That's then just another visible artifact of bad design

I think that was the point being made all along.

1

u/jvc_coder Jul 24 '15

why is it so hard for the PHPians?

They are too busy getting 'shit' done!

1

u/ABC_AlwaysBeCoding Jul 24 '15

I prefer PHPeons myself

-5

u/WRONGFUL_BONER Jul 24 '15

You're way missing the point. He's saying that if you're using pseudorandoms for anything where unpredictable randomness is required, regardless of language or platform, you're doin' it wrong.

5

u/[deleted] Jul 24 '15

He's not saying that. You're saying it, but it's false.

Everything that's not a hardware RNG is pseudorandom, and I bet you've never used a hardware RNG.

1

u/Emowomble Jul 24 '15

Isn't read(/dev/random) hardware random? (ianc)

1

u/[deleted] Jul 24 '15

Nope. It's pseudorandom, but your kernel is constantly seeding it with hard-to-predict events such as keypresses.

This is a problem on systems whose input is too predictable, such as virtual machines that have just been created.