Welcome to reddit's new mobile site
This is in beta, so some features are missing and some stuff is broken. Thanks for trying it out! Learn more.
In which Stackoverflow argues in favour of providing potentially dangerous advice to the masses, as long as it was democratically approved.
Perhaps more interesting is how the mantra of "don't write your own crypto code" is moving upstream - that used to mean, "don't write your own cipher algorithm" but now it's being taken to mean "don't use the provided cryptography library that supplies good ciphers and hashes - get a 3rd party one that wraps it all for you". And that sort of advice comes with its own risks (how are we to know which 3rd party libs are up to the task? Or written by trusted entities?) and resistance (nobody goes to Stack Overflow to be told not to code something).
Love the currently upvoted response with "Edit the answers" or "Post your own answer". Long after Scott made clear that those don't work since edits just get rejected and answering is disabled on a closed question.
The problem with StackOverflow and StackExchange as a moderation system is that anybody who thinks the system is broken leaves, meaning that those who remain tend to assume nothing is wrong and that the usual tools will do the job.
That and the fact that the questions get closed in the first place. The rampant over moderation on stackoverflow kills it for me. Moderate unless proven otherwise! The problem with such "community based" moderation is that it tends to attract the type of person who enjoys moderation and bureaucracy.
It's a bit like Wikipedia in some ways, in that it's a bit too easy to feel like you're making a positive contribution without little effort if you just go in and tinker with what other people have done already.
It seems like the vast majority of useful question threads I come across on stack overflow are closed for violating site rules. It's to the point where I wish another website would come along and replace stack overflow. The community as just as bureaucratic as the English Wikipedia but without all the rules about attempting to be friendly to newcomers.
If you think the English Wikipedia is bureaucratic, you haven't seen the German one, e.g. see the Relevanzkriterien (criteria of notability).
English Wikipedia has just as much requirements for notability, it's just it's spread out over multiple pages. See Category:Wikipedia Notability Guidelines If you really want to go down the rabbit hole check out the Manual of Style. It's literally hundreds of pages long the page you see there is just the summary of the most important stuff. German Wikipedia definitely comes in second and gives English Wikipedia a run for it's money. (If you are interested in editing don't let these rules deter you, Wikipedia has policies encourage people to Ignore All Rules and Be Friendly to Newcomers )
source: former wikipedian (I no longer have time to edit)
We should start promoting an alternative such as /r/askprogramming or perhaps /r/learnprogramming.
Doesn't reddit have it's own issues such as archiving old stuff (so the outdated answers are a problem again) and it's much less searchable.
I think SO is a much better platform for sharing knowledge but I think they intentionally don't want to expand their site to allow stuff that doesn't fit Q&A pattern (stuff that allows discussion or opinion based answers).
On the other I think that's what Quora is and that site is a mess IMO.
I always thought that's why ex-SO employees founded Discourse, as a companion for "stuff that isn't appropriate on SO"
The "don't write your own crypto code" is a simplification of the more nuanced point: Don't write your own crypto code unless you are intimately familiar with modern cryptanalysis and cryptography engineering. I can probably considered fortunate that I was bored and lonely enough to learn these topics with the depth that I have.
How are we to know which 3rd party libs are up to the task?
I don't have any easy answers. As long as the library is open source, you can always review the code. But in order to do so, you need to already be an expert.
And therefore everyone expects everyone else to review the code, and we have yet another OpenSSL.
Unlike a lot of the crypto aristocrats who enjoy the privilege and prestige, I put a lot of skin in the game fixing bugs in popular projects.
https://scott.arciszewski.me/open-source
I don't want to see another OpenSSL happen, and I sacrifice a lot of my free time trying to prevent it where I can.
The "don't write your own crypto code" is a simplification of the more nuanced point: Don't write your own crypto code unless you are intimately familiar with modern cryptanalysis and cryptography engineering.
But, if you'll forgive me, that itself is glossing over my own nuanced point, which is since what we call 'crypto code' is a moving target, it's hard for anybody to know what they should or shouldn't be writing themselves. Developers often think they are doing the right thing by using the standard library's crypto module, using that library's hashes/message digest algos, selecting the recommended options in each case, and deploying that.
Developers today need to know too much about security to make secure software, and I think the blame for that falls mostly on language developers and those who supply their standard libraries.
I think that is because security is a very, very complex subject. You have to be intimate with the process and that itself may not be enough with how fast things get exploited these days.
I think the fault is on both sides, getting secured is almost an afterthought with most companies until some shit happens then all of the sudden it is the most important thing on the planet. To write a decent implementation that is out of your standard is anything but easy. You almost need someone who specializes in security and most regular developers are not up the task (who needs security when you have a huge set of JS and middle tier that you need to finish before the project deadline.)
In which Stackoverflow argues in favour of providing potentially dangerous advice to the masses, as long as it was democratically approved.
it's even more amusing that the most upvoted response to his argument is straightup wrong (you can't answer a closed question, and edits just get ignored/rejected/blocked).
this focus on form over function is by far one of the weakest parts of SO, reddit, and most other typical upvote/downvote sites (as well as analogues like wikipedia). most of these sites assume 1:1 or barely larger vote weighting. but as industries become more technical (especially with software engineering), expertise is not an equal or normal distribution. if you put # of people on the y-axis, and skill level on the x-axis, it's more like a k/x distribution on a logarithmic x-scale. there are a ton of bad people, a decent amount of mediocre people, and as you move farther out on the x-axis, you have these smaller and smaller minorities who are multiple times, or even orders of magnitude better than groups before them. especially in an area like crypto & security, being bad or mediocre has severe negative value.
this is why you have tons of low level website-factory devs hacking together CMSs and plugins for $40-60k, smaller numbers of mid-level coders hovering around $80k, some senior devs in the $120-200k range, and then small minorities making 7 or 8 figures.
companies acknowledge this to some degree with pay, and the unicorn companies just got beat up in an antitrust case for setting up a no-poaching pact to suppress these salary issues. multiple startups (and even google) have tried to set up "expert" Q&A / knowledge base sites (scaling out content creation is always the problem... the far end of the long tail of experts can make ridiculous rates for their time, why would they do it for near free?). it is very undemocratic to say that a single professional opinion can be 10x, 100x, or even 10,000x more valid or valuable than another, but it's reality. acting like this issue doesn't exist is counterproductive. so now how do we fix it?
The problem with weighting expertise is that any implementation of a Q&A website needs to be simple, and hence the two ideas are incompatible. Reddit and stackoverflow are good examples, with a single up/down vote button.
If a voting system should be made around expertise, you either enforce it via culture rules or via the user interface. And both solutions require new users to learn the system. That's almost impossible in practice if the web portal is open for everyone without taking in new users in pools. It's similar to "Eternal September".
In which Stackoverflow argues in favour of providing potentially dangerous advice to the masses, as long as it was democratically approved.
Except it doesn’t. The Meta discussion overwhelmingly sides with the OP, Scott. Moderation is actually a hard problem, and the Stack Overflow community in general is fully aware that it’s not a perfect approach. But so far nobody has come up with a better approach. What’s more, the system seems to be working in this particular instance: Scott has triggered a discussion which is leading to changes in the harmful answers as we speak.
The system failed super hard. Now some of the damage may be undone. I'd hardly call that "working." It's like if your car's brakes failed but you survived the crash because of the air bags. The thing has enough depth to let you survive a failure, but you wouldn't call it a success.
The system “failed” because before Scott nobody bothered to clean up. The system is based on user contribution. As every other system. You simply cannot get something from nothing, and I have no idea how you can justify this implicit expectation.
If you see shit happening (on Stack Overflow or elsewhere), do something about it. If nobody does, then obviously nothing changes. You can’t well ascribe this failure to the system. If anything failed here then it’s the community — which isn’t surprising, considering how much software gets security wrong.
The system failed because it's set up as a democracy where the loudest voices prevail over people who actually know what they're doing. Maybe that's inherent in any democratic system, but that just means they all fail, it doesn't make it not a failure.
You tell me to "do something about it." Why, exactly? I pretty much never use Stack Overflow, so why is it suddenly incumbent on me to fix somebody else's mess?
I’m not appealing to you personally to do something, I’m simply observing that if nobody does anything, nothing happens.
Incidentally, the moderation on Stack Overflow is usually attacked for not being a democracy. (And it isn’t, and that’s a good thing.) There was no “loudest voice” in this particular case. No other voices were drowned out, because there were none (until now, and they appear to be prevailing).
Read the most up voted response, it flat out ignores the points raised by Scott. Also the only mod partaking in the discussion favoured the current state and a if in doubt revert instead of skip policy for edits - one less solution . Of course the discussion can no longer be followed since all relevant comments have been removed - so much for that solution also.
I think the mantra just follows what people do. Used to be that people would routinely write their own "crypto" algorithms (scare quotes because they usually didn't remotely qualify as crypto). Turns out everyone did a horrible job except the absolute top experts (and even they had trouble) so people started saying, don't do that. Then people started using good crypto primitives built by people who could do it right, but they inevitably used them incorrectly and created lots of vulnerabilities. So the mantra became, don't use crypto primitives directly.
We might be seeing another shift towards "don't write your own code that uses crypto libraries, and instead just use higher-level libraries that do it all for you." I commonly see it stated that you should use TLS for data in motion and PGP for data at rest, and that's it. The recent AFNetworking vulnerabilities on iOS are demonstrating that even that can easily be defeated if you fuck up the configuration, so I imagine the mantra will be expanded to include "and for god's sake, do not touch the settings."
In which Stackoverflow argues in favour of providing potentially dangerous advice to the masses, as long as it was democratically approved.
Reading the comments to the post I come off with the impression that SO is much more concerned with preserving its own meta-mechanisms than with the correctness and applicability of the answers it collects. This comment is very telling in my opinion:
If the answers are bad flag them, also don't hound people on third party social networks because you don't like the outcome of the review process.
I can't read it in any other sense than SO actively preventing being susceptible to outside influences, "what happens in SO stays in SO." If you are playing the game of building reputation in SO and you're foolish enough to put pointers to your other social identities be prepared to bear the brunt of being called out publicly.
Whenever I regret having quit SO in disgust some years ago these things come along and I feel reassured again.
Perhaps more interesting is how the mantra of "don't write your own crypto code" is moving upstream - that used to mean, "don't write your own cipher algorithm" but now it's being taken to mean "don't use the provided cryptography library that supplies good ciphers and hashes - get a 3rd party one that wraps it all for you".
Yeah, I found that out when trying to research things at my job. I work on embedded devices that have built-in web pages for configuration, much like a home router. It has to operate independently since it's a standalone device that might not have an Internet connection, and everything is implemented in C, no SQL or PHP or anything of the sort.
So while I'm glad the standard security advice is "don't do it yourself", it's not very helpful for exceptional cases like mine where I have to do it myself.
Perhaps more interesting is how the mantra of "don't write your own crypto code" is moving upstream - that used to mean, "don't write your own cipher algorithm" but now it's being taken to mean "don't use the provided cryptography library that supplies good ciphers and hashes - get a 3rd party one that wraps it all for you".
The problem with crypto isn't so much bad algorithms or algorithm implementation, but that with high level languages, it's nearly impossible to be certain that your plain-text and keys aren't recoverable from the computer/application.
With modern languages and virtualization it's nearly impossible to know with certainty that your plain-text/keys have actually been destroyed when you're done with them, even if you think you overwrote them.
It's also possible to feed bad data to good crypto code and still not get what you thought you wanted, or use good crypto improperly. For example, a hash without a salt isn't all that secure, but without knowing that, a programmer could "correctly" use a known good library and still have weak crypto.
Even if you use provided "probably good" libraries, there's no reason to believe that you're actually using them safely.
In which Stackoverflow argues
Where is the "I AM STACKOVERFLOW, THIS IS MY OPINION" - response?
... in favour of providing potentially dangerous advice to the masses, as long as it was democratically approved.
Where?
The argument that comes closest to your statement is expressed in
You're entitled to think the rules should change, but not to break them prior to them actually being changed
how the mantra of "don't write your own crypto code" is moving upstream
I'm certainly no expert on this topic - much less in python - but this might be a case of the language / core library implementation lagging behind current practices.
My relationship with cryptography is like a little child and a horror movie. I am scared shitless of it and the more I watch the more scared I become. It has very little value for my work (it has value for the product but nobody expects me to know about it and nobody will hold it against me if I fail and won't pay me more if I know more about cryptography). Still I keep reading articles and signing up for Coursera courses on cryptography. I just can't stop :(
Remember the difference between cryptography and security.
Knowing how to build a door lock is a different skill from knowing how and where to install them to keep a building secure. The world only needs a few lock manufacturers, but we need lots of locked doors.
Don't bother learning to write crypto code, just learn how to use crypto tools to properly implement security. Unless you want to learn mindbending math and make a career of it. Then knock yourself out :)
Cryptography is complex, doing it well is difficult which is why the wise old ones suggest using existing libraries for the heavy lifting.
Having said that, you shouldn't be scared of it or threatened by it. The percentage of all developers who actually understand how to do it well is very small. Plenty of people think they know and will spout advice at you but it can be inconsistent (because it's wrong) and that just adds to your confusion if you take it to heart. You are doing the right thing by learning it for yourself rather than taking the internet's answer.
I think having a working knowledge of cryptography will be a very powerful skill moving forwards. If you look at the way tech companies are going, everyone is moving to SSL/TLS/HTTPS. I've used encryption in 2 recent projects at work, and I feel like it's making sense to me at last. My first work encryption project was about 6 years ago (haven't done any crypto between then and now), and looking back at it there are several things that could be done a whole lot better. But that's just the nature of coding, every time you look at code you wrote a couple of years ago it SUCKS. If it doesn't, you've stopped learning! Even that product was a big improvement on what came before it, and that's the crux of the game. You just gotta improve on what came before.
I presume you mean "fail" as in "fail to become an in-house cryptography expert" and that if you actually fail to keep your employer's product secure due to choosing insecure libraries/etc. it will be held against you.
I expect that it won't be held against me at least as long as I mention the need for an expert (which I will) and they ignore me. Let alone that they know I am not an expert and if they give me a task to develop something with cryptography I must assume that they just want me to send/decrypt messages to some system that uses cryptography. If they wanted real security they would hire an expert.
Of course all this doesn't mean that I will be happy to fail or that I won't do my best. It simply means that I won't feel responsible if I fail.
Is it really that big of deal to use a "kinda-not-really" random value for an IV? I've always felt there's so much emphasis put on getting "true random" values for encryption. I understand the value from a theoretical cryptographic view, but from a practical implementation view -- what are the real chances someone is going to be able to crack my "mostly random" value?
TL;DR:
MCRYPT_RAND is terrible for IVs
Why?
One of the worst things that can happen is that with rand(), you have a theoretical maximum keyspace of 232 possible outputs. Which means after 216 encryptions, you have a 50% chance of a collision. (See also: Birthday paradox.)
This means after about 65,000 encryptions you can expect to have two encryptions performed with the same key and the same IV but a different message.
The collision happens with MCRYPT_DEV_URANDOM after 264 encryptions.
It seems that you can't do self-posts in r/programming.. But I'd like to start a discussion.
Lets say I'm a n00b PHP developer - Rockstar Level. I know how to make a signin form. The relevant PHP looks like this:
$sql = "SELECT * FROM users WHERE username = $_GET[username] AND password = $_GET[password]";
But I want to do better, so I go to SE and ask. Most of the time, the response is "encryption is hard, use a lib". Maybe if I post my rockstar code for critique, someone would take pity on me. Maybe I do research and come up with something better. Maybe I get this:
$sqli = "SELECT * FROM users WHERE username = mysqli_real_escape_string($_POST[username]) AND password = bcrypt(mysqli_real_escape_string($_POST[password]), $SALT);
But now what? Is this good code? To be honest, the first result in Google is for code that isn't even this good. The first result in Bing is for code that looks like my first code block. Yet I can pat myself on the back, and put my code in production thinking it's good, because it's better than the first result in both Google and Bing.
As a community, you can't just say "encryption is hard, use a lib". Hell, unless you lib only has 2 functions "tryLogIn($user,$pass)" and "logout()", some genius will probably be able to write enough spaghetti code to open themselves up to a timing attack that at the very least will leak data about email addresses in your system.
But I used a library
And you still screwed up.
But I asked at SO and they said to use a library to do it for me. Because "Encryption is hard, leave it to the experts".
And you did exactly what you should have done.
So what went wrong?
I'm not sure. What did go wrong?
Personally, I think the problem is the following quote:
don't write your own crypto code
Not because it's bad advice, but because it obscures the issues that you need to be aware of. It generally lowers the availability of information to the point where your average developer could spend a full working day trying to find "good" code examples, and never get beyond what I posted.
Let me ask you this; /r/programming:
CodeIgniter has a function that sanitizes SQL input. Part of it removes whitespaces. If I want to write a login function, do I need to remove the whitespaces before hashing the input? I can predict the answer already:
don't write your own crypto code
But what if I want to -
don't write your own crypto code
But -
don't write your own crypto code
And generally, I feel like the whole field suffers because of it.
With apologizes to /u/kylotan for stealing the quote verbatim from his response. I'm not singling him out specifically, but rather the idea of the quote, that anything having to do with *crypt* is difficult and should be avoided by plebian developers
Another interesting viewpoint (which is actually closer to how I feel about non-production code): http://www.cryptofails.com/post/75204435608/write-crypto-code-dont-publish-it
You make it sound like I would disagree, but I don't. I think there is something slightly absurd in always punting the problem upstream, for reasons I touched upon. 3rd party libs aren't always better and it's simply not feasible for anybody who wants to put something on the web to pay for a full security audit or for a top-tier security-conscious developer to go through it. So there has to be room for half-way solutions.
Your examples show 2 problems though, because nobody should be using SQL sanitisation functions. How a database wants to escape data should be pushed down to the database itself, not handled in your language with string-fiddling functions. But, again, the problem here is down to the language and library providers. Not only did PHP create a whole generation of "everything via strings" developers, but SQL's syntax predates all these security concerns and was not designed to handle untrusted input.
In my opinion there's little point trying to educate the average developer about writing better security code or to tell them to stop doing what they're doing, as the Dunning-Kruger effect makes it a losing battle in both cases. The better approach is to create safer APIs, ones which cannot be used in an unsafe way if they are being used at all.
In my opinion there's little point trying to educate the average developer about writing better security code or to tell them to stop doing what they're doing, as the Dunning-Kruger effect makes it a losing battle in both cases.
The problem with this response is that you're doing exactly what I suggest people not do - twice in fact!
The first time, you explain that putting random strings into SQL statements is a bad idea. Okay, check. But isn't that what a auth lib is doing, or an ORM? Taking a random string, and -eventually- putting it into a SQL statement? So why is it okay for someone else's library to do this, and not me? Is it because I'll screw up and you don't trust me? remember this point, I'm coming back to it.
The second time you do it is when you specifically call out the use of the mysqli function. "nobody should be using SQL sanitisation functions" So how should I do it? What would you consider the "proper" way? An ORM? Parameterized inputs? But for a simple query, isn't that just sanitization by a different name?
Of course the "proper way" is to let someone else handle it for you, but then what happens when you come across this page on symfony which provides instructions on how to create a custom password encoder.
So now, you have a case where someone chose to implement the Custom Password Encoder, did it incorrectly, but thinks their site is secure because they're using the symfony authentication framework.
But when we keep security and encryption information hidden, it becomes so hard to find "good" examples that even high profile frameworks end up screwing up - lets get back to my point on trust: CodeIgniter checks for sanitization on input. And, its sanitization checks aren't comprehensive. Therefore we can assume that the CodeIgniter devs screwed up. But the thing is, at one time they were the #3 PHP framework. If we can't trust the #3 framework to get it "right", who should we trust?
The problem is that nobody knows security, and instead of trying to teach it even just a little bit, the community response is to shut up and use a library. Frankly, that's unsustainable. And considering the size of the PHP install base, is naïve to assume will happen.
Also, I mean no disrespect to you, kind internet stranger. PHP has many problems (such as everything is a string) but I don't mean we should re-write PHP to fix this; rather we should look at providing information to developers on how to not write sloppy everything-is-a-string code. Yes, even that statement is problematic, I know, it's PHP... :sad face:
I don't think this is a black and white issue... however, why would you use a language like PHP to implement any cryptography from scratch? I can understand if it's for educational purposes, or just for fun, but I would strongly question the motivations and competency of a developer who is doing this on production software.
- PHP is a web development language. It wasn't made for maths, therefore it's not optimized for very large numbers, so you're stuck using the relatively slow BCMath and GMP. Whereas in C you can do everything in polynomials which means lightening fast calculations using bit shifting.
- You'll get higher quality, faster development and testing time, if you use an existing tried and tested library.
I like PHP, but it seems to be a language which attracts a lot of 'developers' who don't follow best practices.
I would strongly question the motivations and competency of a developer who is doing this on production software
https://github.com/defuse/php-encryption/commits?author=sarciszewski
Thanks for questioning my competence. :(
PHP is a web development language. It wasn't made for maths
You realise someone's writing a kernel in JS, right?
Do you think JS is an appropriate language for a kernel?
The appropriate language for a kernel you want to write is one you know that compiles to machine code. Providing you can compile JS to machine code it makes little difference in terms of performance.
People use PHP because they know PHP.
It turns out that programmer productivity is massively more important than performance. And when you hit the performance bottleneck you can just use a compiler to cross-compile to PHP and suddenly the PHP is as good as C at big numbers.
HipHop exists because it made more economic sense for Facebook to recompile to PHP than switch to C and re-train all their devs. That alone tells you why suggesting that language choice is about performance is not a rational position.
Your argument about PHP 'not being optimised for large numbers' is not actually true. Your argument is actually that the Zend VM is not optimised for large numbers. But we don't have to use PHP as a scripting language on some VM, we can treat it as a compile-able language.
I'm not familiar with PHP or the mcrypt library, but why do you specify MCRYPT_RIJNDAEL_256 as a bad thing? Does it not use the aes blocksize? I looked at the library spec and they don't even provide named AES implementations, which is bad enough.
Otherwise, #6 that you listed is actually pretty good, once they use a constant time comparator for the mac. I'm not sure how secure Blowfish is nowadays, but the only other good option would be Twofish or Rijndael128.
MCRYPT_RIJNDAEL_256 is often used when people think they're using AES-256. It's bad because it's far less studied than AES and might have design flaws that AES does not. A more conservative approach is to use a well-studied algorithm.
And #6 is phenomenal if they get rid of the timing side-channel. :)
Unless I'm completely wrong here, and it's been a while since I've done crypto, Rijndael is AES. It's not some different thing as you're suggesting, or a "compatible. "
Rijndael is just a portmanteau of the two AES authors, Vincent Rijmen and Joan Daemen.
AES is a subset of Rijndael, so they aren't necessarily the same. And in this case, they aren't. I'm not sure what key size MCRYPT_RIJNDAEL_256 uses, but it uses a block size of 256 instead of the 128 that the three AES variants use. Small difference, but in modern crypto any tiny thing can potential be a cause of issues. /u/sarciszewski is right to recommend AES instead, because it is far more studied.
https://www.schneier.com/blog/archives/2009/07/another_new_aes.html
People assume because 256 is larger than 128 it's better - when in fact AES 256 has piss poor key scheduling (by comparison).
I love how the various suggestions on what to do about the problem are completely contradictory. Stack Overflow, your hilarity never fails to disappoint.
Not trying to cut a lance on StackOverflow's favor here, but by the time you've googled "php cryptography" your application is already doomed.
But if you append "expert" to your query and proceed to hire someone who can write it for you, it's salvageable.
Maybe.
Yes. Or if you remove "php". Best course of action would be to do both.
Or realise that PHPs use of crypto libraries is generally the same as any other high level language, and therefore you're projecting perceived deficiencies with PHP developers coding insecurely on the whole platform.
With modern frameworks it's getting harder than ever to commit cardinal sins such as raw SQL concatenation without using prepared queries, not sanitising or filtering incoming data etc etc
Nitpicking for a second:
With modern frameworks it's getting harder than ever to commit cardinal sins such as raw SQL concatenation without using prepared queries, not sanitising or filtering incoming data
It's not harder. mysql_query() is still as available as it always has been, and no framework that I know of is going to stop you. This is, of course, true of many languages, and not a bad thing by itself.
Back to the main point:
Or realise that PHPs use of crypto libraries is generally the same as any other high level language, and therefore you're projecting perceived deficiencies with PHP developers coding insecurely on the whole platform.
PHP's development culture is one that encourages shoddy, if-it-works-dont-fix-it, broken development. Searching for a "php cryptography expert" makes no more sense than searching for a "script kiddie cryptography expert" or a "clueless cryptography expert". It's a search term that will only diminish the quality of the results.
Get a good cryptography expert, and make him code PHP (or anything enlse, really)
Searching for a "php cryptography expert" makes no more sense than searching for a "script kiddie cryptography expert" or a "clueless cryptography expert".
Ouch. That would be a sick burn on a dream-crushing scale if it was substantiated by facts.
There is nothing inherently insecure about PHP or PHP cryptography. It's as secure as any major web programming language, and that's why it's trusted by so many websites, including many of the biggest sites on the web.
It does have a history of allowing, or sometimes encouraging bad habits that lead to horribly insecure apps, but that has almost entirely changed. While it's always been possible to build secure apps with PHP, and these days it also does a good job of encouraging state of the art best practices. Especially if you're using one of the new frameworks that are becoming so popular lately (notably Laravel).
Amazing contributions. Screw stack exchange for letting the internet be polluted by nonsense while you're begging to provide a proper alternative.
Pick any topic and you'll find wrong answers in stackoverflow.
There's a way to weed out the wrong answers. If you don't know how to do it, then stackoverflow isn't your biggest problem. In a way stackoverflow may help you to learn the skill.
If you don't know anything about cryptography, how will you tell an answer is ever wrong? It will appear to work, and as far as you know, that's all you need.
Conversely, if you don't know anything about cryptography, then you don't know if it "appears to work". You don't know any attributes about how it should work.
There's name for this. It's called cargo cult programming. The remedy is evidence, observations, knowledge and proofs.
If your plaintext turns in to what appears to be random data when you encrypt something, and you get your plaintext back when you pass the random data to be decrypted, then encrypting/decrypting "appears to work".
Are you generating keys with rand()? Are you using ECB with multi-block data? Are you using a predictable/known IV with CBC? Are you not authenticating? Are you using MAC-then-encrypt? It will still "appear to work" if you do any of those, and they're all wrong.
Yeah. The problem is the person thinks that it "appears to work", although he doesn't have enough knowledge or evidence to confirm that.
It may feel like hopeless to correct such problem, but it's the correct thing to do here. You know, it won't apply just to cryptography! And the solution isn't to clip out the wrong answers off the internet.
This is not just a programming related problem. You still get to see those "microwaving my iPhone to charge it" -stories, although it's months old thing. The stuff is read from the internet and simple additional research in internet would prevent the harm done.
if you have 1 year experience with software, how can you tell in general what's wrong and what's good? Todays biggest problem (IMO) is that, youngsters think about they self too good, they pick some point (because someone they trues recommended or because one of their idol suggested that, or just because masses think it's right) and they start writing blogs and comments, how this is only good solution for all the problems (because it worked for my one project and because Jhony Bravo recommended, so it should be true). And actual experts with >30 years of experience don't have time or will to comment such nonsense, and this of course makes previous person write even often. And if any will try to criticizes, they will have millions of links on internet to proof, that they are correct and army of same type of persons, whom will confirm, that his right.
So what IS the best advice? I assume it's this solution?
Why is unauthenticated ciphertext automatically considered a problem? If you need authentication, sure, use authenticated encryption. And if you don't want to do a bunch of extra work to make it secure, use Encrypt-then-MAC. But if you don't need authentication to begin with, not having it doesn't constitute a problem.
Why is unauthenticated ciphertext automatically considered a problem?
See: attacking unauthenticated encryption
Further reading
Having recently been working on Mutual SSL, if one end is a webserver that has support (e.g. Apache), this may be the best solution. (Assuming you don't turn SSLVerify off in production.) This is definitely agreeing with the "Don't write your own crypto".
[edit] Apache's "default-ssl" config file is very well documented, and only a few things need to be turned on. I believe it's possible to use PHP for the server end instead of a web server as well, but that's more work, and more subject to the "do your own" issues.
I've never seen StackOverflow as a reliable source of advice on crypto (and I work with crypto all the time).
What we really need to address this problem are high level cryptography frameworks that leave nothing up to the user. They should simply not be able to encrypt or sign data in a a problematic way. They should, however, be able to decrypt badly encrypted data, if for no other reason than to migrate it to better practices.
NIST Randomness Beacon Summary: NIST is implementing a prototype source of public randomness. The prototype (at https://beacon.nist.gov/home) uses two independent commercially available sources of randomness, each with an independent hardware entropy source and SP 800-90-approved components.
The Beacon is designed to provide unpredictability, autonomy, and consistency. Unpredictability means that users cannot algorithmically predict bits before they are made available by the source. Autonomy means that the source is resistant to attempts by outside parties to alter the distribution of the random bits. Consistency means that a set of users can access the source in such a way that they are confident that they all receive the same random string. Description:
The Beacon will broadcast full-entropy bit-strings in blocks of 512 bits every 60 seconds. Each such value is time-stamped and signed, and includes the hash of the previous value to chain the sequence of values together. This prevents all, even the source, from retroactively changing an output packet without being detected. The beacon keeps all output packets and makes them available online.
DRBG Beacon System Diagram Uses:
Tables of random numbers have probably been used for multiple purposes at least since the Industrial Revolution. The first published table appears to be by the English statistician L.H.C. Tippett. In the digital age, algorithmic random number generators have largely replaced these tables. The NIST Randomness Beacon expands the use of randomness to multiple scenarios in which the latter methods cannot be used. The extra functionalities stem mainly from three features. First, the Beacon-generated numbers cannot be predicted before they are published. Second, the public, time-bound, and authenticated nature of the Beacon allows a user application to prove to anybody that it used truly random numbers not known before a certain point in time. Third, this proof can be presented offline and at any point in the future. For example, the proof could be mailed to a trusted third party, encrypted and signed by an application, only to be opened if needed and authorized.
NIST encourages the community at large to research and publish novel ways in which this tool can be used. A few examples of applications are described below:
Unpredictable Sampling
New Secure Authentication Mechanisms
Secure Multi-party Computation
A Quantum Source:
Commercially available physical sources of randomness are adequate as entropy sources for currently envisioned applications of the Beacon. However, demonstrably unpredictable values are not possible to obtain in any classical physical context. Given this fact, our team established a collaboration with NIST physicists from the Physical Measurement Laboratory (PML). The aim is to use quantum effects to generate a sequence of truly random values, guaranteed to be unpredictable, even if an attacker has access to the random source. In August 2012, this project was awarded a multi-year grant from NIST's Innovations in Measurement Science (IMS) Program. IMS awards highly competitive projects designed to explore high-risk, leading-edge research concepts that anticipate future measurement and standards needs of industry and science. For more information on this collaboration see http://www.nist.gov/pml/div684/random_numbers_bell_test.cfm Locality-Loophole-Free Bell Test A space-time diagram illustrating a locality-loophole-free Bell test. In this test, entangled photons are verified to have correlations that exceed the maximum level possible with any predetermined (or classical) states. To demonstrate this unequivocally, it is important to make sure that the measurements performed on one photon cannot, by any means within the bounds of physics, influence the measurement of the other photon. Such an influence, if it were to exist, could allow fully predetermined states to appear to share quantum correlations. Conducting the two measurements outside of each other's light cones ensures this measurement independence. In the space-time diagram above, the speed of light is depicted by rays at ±45 degrees, and also represents the maximum speed at which information about any event could (conceivably) propagate away from the origin of the event. Therefore, positions outside the cone formed by the rays from any event represent locations and times that could not possibly have received any information from the event. In the loophole-free test illustrated above, entangled photons are emitted from the source and propagate in opposite directions towards receivers Alice and Bob. At some point in time, indicated by "i" and "j," Alice and Bob each independently choose how to measure the properties of the photon each will receive. To conduct a locality-loophole-free Bell test, Alice and Bob must complete their chosen measurements (Ai,and Bj, determining results a and b, respectively.) before any information about the other's choice could possibly reach their location; Alice must complete her measurement before the rays emanating from the event "j" intersect her location, similarly Bob must complete his measurement outside the light cone of event "i." Closing this and other loopholes in the Bell test provide certification that no information about the state of the photons could have been available prior to its observation, assuring that the correlations could not have been predetermined. That guarantee of no predetermination of the photon system and its measurement results, will ultimately be used to produce random bits that can be assured to be both random and unknown to anyone before a certain time.
End Date: ongoing Lead Organizational Unit: itl Staff:
Rene Peralta 301-975-8702 rene.peralta@nist.gov
Mike Bartock Larry Bassham Joshua Bienfang Harold Booth Prof. Michael Fischer (Yale University Computer Science Dept) Scott Glancy Dr. Michaela Iorga Stephen Jordan John Kelsey Emanuel Knill Paulina Kuo Yi-Kai Liu Alan Migdall Sae Woo Nam Andrew Rukhin Murugiah Souppaya Xiao Tang
WARNING: DO NOT USE BEACON GENERATED VALUES AS SECRET CRYPTOGRAPHIC KEYS.
Whats with the warning. Are you making some kind of point?
The author is the OS developer equivalent of John Nash--a genius, but also schizophrenic. Best to leave him be.
That said, the warning is correct. The random numbers in question comes from server controlled by a third party, and then transmitted over the Internet (albeit by SSL). The third party could be logging data, so they would have the most important information needed to generate your crypto keys without you knowing.
This also applies to random.org.
He's basically just throwing a hissy fit because he deems every code that doesn't use his favorite crypto wrapper is insecure. And hounding people on social media outside SO when they disagree with him.
edit: downvote all you want, I stand by my comment. OP is mad because he tried to insert a crypto library in accepted answers thus substantially changing the answer and the edits got rejected because of that.
He's basically just throwing a hissy fit because he deems every code that doesn't use his favorite crypto wrapper is insecure.
Not quite. I've listed specific vulnerabilities in the examples others have provided.
Hissy fit? I'll accept that characterization, as I was frustrated earlier by their editorial process.
Because of the reason you stated? Sorry, I disagree here.
If the current answers have known insecurities in them, and his favorite crypto wrapper fixes those securities, could you tell me how this is a bad thing for him to be doing?
For the same reason that I am not allowed to edit your comment to make it (objectively or subjectively) better.
On SO, if you think an answer is poor quality or has problems you downvote it, make a comment and/or provide your own answer. You don't just change other people's answers. Editing should be reserved for small mistakes.
or provide your own answer.
If its not locked..
For the same reason that I am not allowed to edit your comment to make it (objectively or subjectively) better.
That is true, and declaring yourself grand-editor who gets to re-purpose an upvoted answer would lead to the exact same problem of upvoted wrong answers, they just could now be wrong answers that used to be right.
Its still scary how many questions have potentially dangerous top answers that future viewers have no reason to doubt the safety of unless someone comments AND the comment gets enough visibility. It'd be nice if there was some way to call for a vote to at least edit code samples to put a warning disclaimer about some potential issue, at least that would jump out more to the copy and paste coders out there.
Just going to point out that where he says "This was insecure until I submitted my answer", he doesn't provide the answer in a useful, copy-pastable format like the "insecure" answer does. He instead provides a load of reading material and a link to a library which might handle it for you.
This isn't as useful as he thinks. People want quick answers, not a lecture on security. Yes, that's a problem, but no, your way of solving it isn't quite the right one.
Even a code box on there with the library as a require, and an example encrypt() and decrypt() routine at the top would make the answer 100% more compelling to the average SO user inbound from Google for a working solution.
Noted. I'll make the necessary amendments.
Woo!
http://stackoverflow.com/posts/30159120/revisions
Unfortunately, this is starting to happen in a lot of questions from what I have seen. People are writing mini-blog posts in questions.
I actually kinda like this, provided they write good content and put the quick answer at the top.
Sure, google is 98.9% of our job, but do people really refer to stackoverflow questions for problems where security is paramount? that seems terribly discomforting, but then again, im drunk at 3pm, so i just may be dumb...or maybe awesome...i feel awesome, so im hoping it's the latter, but that just may be the sauce talking. i do feel sushi and a hadouken coming on, so if any one wants some, $5 a pop for either. i wouldnt trust the sushi though. i've never made it before and the catfish has been sitting on the bathroom floor for 2-3 days. i can't shoot a hadouken either. i guess what im saying is that if someone wants to give me $5 for no reason, I would be ok with that.
Absolutely, yes
Bravo and long may you continue
Good luck with the catfish.
"Defaults matter"
Onus is not removed from the Googl-er(?), bu this rationale could be used for really anything. Under such a paradigm, I'd extend blame on QA, OPSec, the code reviewer, and management who either doesn't staff/value those 3 things.
But management doesn't really care about what I or many people think. The real ideal is "security as a culture", but security is quickly in a race to be "t3h sexy" vendorized, all-in-one walled garden.
Mistakes Shouldn't Happen is not really all that useful of a thought beyond bare competence (which is, yes, something we may be talking about here). People debug their code, QA their code, run it through multiple environments, and use many heuristic and analytical tools to make sure "Features Work". What rigor is put towards Security? Do people run snort/burp against test-->stage-->prod? Are security failures a "gate" to prod?
Security is inherently onerous, diligent, and dutiful. If you're talking about a guy that is copy pasting code from SA for his PHP, he probably has a lot more "failures" in his security modeling than encryption.
tl;dr security is hard.
Fine, but then I don't see any problems here at all. If people cannot be bothered to learn anything they might as well use md5().