|
Or at least PBKDF2, an RFC-specified, expert-reviewed mechanism. The circles I wade in tend to prefer it to even blowfish/bcrypt. Here's a library for PHP 5.3+ that implements it well.
|
#
?
Apr 25, 2012 23:54
|
|
|
|
| # ? May 28, 2024 23:14 |
|
|
Bhaal posted:
Wait till you discover SCADA vulns 
|
|
#
?
Apr 26, 2012 00:34
|
|
|
A co-op student at my workplace checked in a method called "addCameraToDatabase". The first thing it does is delete all cameras of that model and manufacturer from the database. Why.
|
|
#
?
Apr 26, 2012 00:55
|
|
|
ShadoX posted:And now the real answer: Parameterized queries. Suspicious Dish posted:All of which are the wrong solution, and can be bypassed in novel ways. Use prepared statements.
|
|
#
?
Apr 26, 2012 00:58
|
|
|
Strong Sauce posted:prepared statements/parameterized queries have only been in PHP since ~5.0, that's not exactly a solution I could have used.  Holy gently caress.
|
|
#
?
Apr 26, 2012 01:02
|
|
|
Thanks all for the advice. Encryption's never been something I've followed too closely after understanding the basic mathematical concepts behind it. When it comes to choosing an encryption algorithm I just took a "when in Rome" attitude for best practices by going off of big ticket LAMP applications that I've worked in. Apparently "Rome" sucks at encryption best practices, too.
|
|
#
?
Apr 26, 2012 01:03
|
|
|
Bhaal posted:Thanks all for the advice. Encryption's never been something I've followed too closely after understanding the basic mathematical concepts behind it. When it comes to choosing an encryption algorithm I just took a "when in Rome" attitude for best practices by going off of big ticket LAMP applications that I've worked in. Apparently "Rome" sucks at encryption best practices, too. MD5, SHA-1 et.al. are not encryption algorithms, they are cryptographic hashes. They don't encrypt data, they fingerprint, and are designed to make it very hard to deliberately produce two different inputs that give the same output (generate a collision). However, both MD5 and SHA-1 have been broken, there are known ways of generating collisions with relatively little computation.
|
|
#
?
Apr 26, 2012 01:10
|
|
|
Ender.uNF posted:
Well PHP did have mysql_real_escape_string which works just fine (and still does) in preventing SQL injections as long as you craft the SQL string properly, and there were libraries that emulated parameterized queries that essentially did some scrubbing of the input. Obviously with the new PDO libraries it looks much cleaner and makes it less-prone to developer laziness.
|
|
#
?
Apr 26, 2012 01:12
|
|
|
tef posted:Wait till you discover SCADA vulns Problem: An undocumented backdoor account exists within all released versions of RuggedCom's Rugged Operating System (ROS®). The username for the account, which cannot be disabled, is "factory" and its password is dynamically generated based on the device's MAC address. Multiple attempts have been made in the past 12 months to have this backdoor removed and customers notified.
|
|
#
?
Apr 26, 2012 01:22
|
|
|
nielsm posted:MD5, SHA-1 et.al. are not encryption algorithms, they are cryptographic hashes. They don't encrypt data, they fingerprint, and are designed to make it very hard to deliberately produce two different inputs that give the same output (generate a collision). However, both MD5 and SHA-1 have been broken, there are known ways of generating collisions with relatively little computation. The issue with use of hash algorithms like MD5 and SHA-1 for hashing passwords is unrelated to attacks for MD5 and SHA-1. They're both not resource intensive algorithms, which makes brute-force searches for the plaintext feasible for crappy passwords on very parallel hardware.
|
|
#
?
Apr 26, 2012 01:23
|
|
|
No-one tell ShoulderDaemon that you're talking about crypto, he's had enough this week
|
|
#
?
Apr 26, 2012 02:09
|
|
|
McGlockenshire posted:Or at least PBKDF2, an RFC-specified, expert-reviewed mechanism. The circles I wade in tend to prefer it to even blowfish/bcrypt. Here's a library for PHP 5.3+ that implements it well. Here are reasons not to recommend PBKDF2: http://news.ycombinator.com/item?id=3725723 The first one is important.
|
|
#
?
Apr 26, 2012 02:18
|
|
|
shrughes posted:Here are reasons not to recommend PBKDF2: http://news.ycombinator.com/item?id=3725723 The first one is important. While that point is true, it's also simple enough to both DIY and verify that it's actually working correctly.
|
|
#
?
Apr 26, 2012 05:57
|
|
|
McGlockenshire posted:While that point is true, it's also simple enough to both DIY and verify that it's actually working correctly. How do you verify that it's actually working correctly?
|
|
#
?
Apr 26, 2012 07:03
|
|
|
shrughes posted:How do you verify that it's actually working correctly? Prove it in Coq :iamafag:
|
|
#
?
Apr 26, 2012 07:06
|
|
|
shrughes posted:How do you verify that it's actually working correctly? check to see that it generates the correct result for 'hello world'
|
|
#
?
Apr 26, 2012 07:32
|
|
|
Aleksei Vasiliev posted:check to see that it generates the correct result for 'hello world' How do you know what the correct result is?
|
|
#
?
Apr 26, 2012 07:33
|
|
|
shrughes posted:How do you know what the correct result is? Verify against the reference implementation?
|
|
#
?
Apr 26, 2012 07:47
|
|
|
Suspicious Dish posted:Verify against the reference implementation? PBKDF2 is described as agnostic to the underlying cryptographic primitives, as well as being parametric in iteration count and key length. This means that there may not be a "reference implementation" easily available for the particular combination of parameters chosen for your implementation. It is much harder for amateurs to verify correct implementations of PBKDF2 than it has any right to be.
|
|
#
?
Apr 26, 2012 07:52
|
|
|
Goddamn, never roll your own crypto implementation. How hard is that? It's literally less work and cheaper to use a professionally written and publicly licensed library.
|
|
#
?
Apr 26, 2012 07:58
|
|
|
shrughes posted:How do you know what the correct result is?
|
|
#
?
Apr 26, 2012 08:59
|
|
|
now you have two problems
|
|
#
?
Apr 26, 2012 09:37
|
|
|
Make sure you keep the unhashed passwords around when you find a bug in your DIY cipher, you can fix it and then regenerate all the hashes!
|
|
#
?
Apr 26, 2012 09:55
|
|
|
Burn everything down and replace it with Kerberos.
|
|
#
?
Apr 26, 2012 13:54
|
|
|
Hammerite posted:Also, I just found out that the PHP development team is planning to deprecate the mysql extension. Well I never. Based on the speed at which the PHP development team usually moves, I'm assuming that means 20 years from now, bargain basement hosting servers running PHP will finally start logging warnings about how mysql_* has been deprecated since version 9.0 (which will have been released in 2021). The log files will never be read, of course.
|
|
#
?
Apr 26, 2012 16:45
|
|
|
Well this codebase is just  So after bringing this site up to the CTO I luckily didn't get pushback on fixing it because if anything else this falls deep in CYA territory. Now I've got the lovely task this morning of getting the most egregious security flaws scrubbed out of this site. Oh hey, check out their mysql_connect.php: php:<?
DEFINE ('DB_USER', 'xxxx');
DEFINE ('DB_PASSWORD', 'xxxx');
DEFINE ('DB_HOST', 'localhost');
DEFINE ('DB_NAME', 'xxxx');
// Make the connnection and then select the database.
$dbc = @mysql_connect (DB_HOST, DB_USER, DB_PASSWORD) OR die ('Could not connect to MySQL: ' . mysql_error() );
mysql_select_db (DB_NAME) OR die ('Could not select the database: ' . mysql_error() );
// Function for escaping and trimming form data.
/*function escape_data ($data) {
global $dbc;
if (ini_get('magic_quotes_gpc')) {
$data = stripslashes($data);
}
return mysql_real_escape_string (trim ($data), $dbc);
}*/
$images_dir = "images/products";
?> The commented function explains why a lot of their queries needlessly wrap post/get variables around parens, like so: php:<? $query = "SELECT id,blah FROM mytable WHERE id='".($_GET['id'])."'"; ?>
|
|
#
?
Apr 26, 2012 19:40
|
|
|
Bhaal posted:I've never seen db info registered as global constants but I'm guessing it's not a good idea. How else would you do it?
|
|
#
?
Apr 26, 2012 19:56
|
|
|
In a configuration file?
|
|
#
?
Apr 26, 2012 20:21
|
|
|
pokeyman posted:In a configuration file? Sure, you put that information in a configuration file or define it in a configuration script, I'm not seeing the distinction, other than the fact that having to instruct the scripting engine to parse a file to get the credentials is pointless extra work. e: ↓ also true. Hammerite fucked around with this message at 20:36 on Apr 26, 2012 |
|
#
?
Apr 26, 2012 20:24
|
|
|
Insofar as PHP goes, having the config is a PHP file is typically better because your chances of the server serving that file directly are alot lower than if it is sitting in config.inc or whatever. Personally I'd use a nested hashtable by environment, YMMV.
|
|
#
?
Apr 26, 2012 20:30
|
|
|
Well, you put it in a config file and then you have a different config file locally for the development environment, a different config file for a test environment, a differing config file for a staging environment, etc. Developing against the production database is a practice limited to PHP shops. Nothing saying the config file itself can't be a PHP file. (Also, from what I've seen about PHP variables and string interpolation, the last place I'd want my db credentials is in a global constant that all of my lovely scripts have access to and can possibly be teased enough to output.)
|
|
#
?
Apr 26, 2012 21:01
|
|
|
pokeyman posted:Well, you put it in a config file and then you have a different config file locally for the development environment, a different config file for a test environment, a differing config file for a staging environment, etc. Developing against the production database is a practice limited to PHP shops. Yeah, it sounds like we are agreeing with one another as far as that goes. pokeyman posted:(Also, from what I've seen about PHP variables and string interpolation, the last place I'd want my db credentials is in a global constant that all of my lovely scripts have access to and can possibly be teased enough to output.) Apart from doing something braindead like eval'ing untrusted data I have a hard time seeing how that could happen accidentally.
|
|
#
?
Apr 26, 2012 21:11
|
|
|
Hammerite posted:Apart from doing something braindead like eval'ing untrusted data I have a hard time seeing how that could happen accidentally. Accidentally removing the leading < while editing your script. Live. This happened to Tumblr a while ago, I don't remember if anything came of it.
|
|
#
?
Apr 26, 2012 21:17
|
|
|
yaoi prophet posted:Accidentally removing the leading < while editing your script. Live. I think that qualifies as "absolutely braindead"
|
|
#
?
Apr 26, 2012 21:19
|
|
|
It just seems to me you shouldn't have that information existing beyond the scope of its need. Not that it's terribly likely something will happen with it, but having your DB connection credentials available anywhere during runtime if there was any upstream DB interaction just seems a little reckless when you can easily have it fall out of scope after the connection's been made, and keep that info at rest somewhere outside the reach of webroot or whatever you happen to be using so it can never accidentally be served up plain.ShadoX posted:I think that qualifies as "absolutely braindead"
|
|
#
?
Apr 26, 2012 22:35
|
|
|
Sorry if I keep making GBS threads up this thread but this site is just.. just...  php:<?
$file_path = '/home/betasite/reqsRes/' . $_GET['id'];
if(filesize($file_path) != FALSE){
$fp = fopen($file_path,"r");
$contents = fread($fp,filesize($file_path));
header("Cache-Control: no-cache");
...
header('Content-Length: '. filesize($file_path));
echo $contents;
}?>
|
|
#
?
Apr 27, 2012 00:10
|
|
|
Haha well at least it's not exec().
|
|
#
?
Apr 27, 2012 00:14
|
|
|
Hammerite posted:Apart from doing something braindead... How many PHP sites do you know that don't do something completely braindead somewhere?
|
|
#
?
Apr 27, 2012 14:43
|
|
|
ToxicFrog posted:How many PHP sites do you know that don't do something completely braindead somewhere? I'd extend that to software in general, to be honest. As soon as it's complex enough, at some point, something braindead is bound to be in there.
|
|
#
?
Apr 27, 2012 15:20
|
|
|
|
| # ? May 28, 2024 23:14 |
|
|
Stealing links from HN: http://stackoverflow.com/questions/4456438/how-can-i-pass-the-string-null-through-wsdl-soap-from-as3-to-coldfusion-web
|
|
#
?
Apr 27, 2012 21:02
|
|