|
hexadecimal posted:Lol yea I know, right? I coded this as fast as I could at the time to meet the dead line and and didn't give it much thought. But why did you think of !(x^y) before (x == y)??????
|
# ? Jan 8, 2009 22:23 |
|
|
# ? Jun 3, 2024 23:46 |
|
narbsy posted:But why did you think of !(x^y) before (x == y)?????? I honestly don't know. I had a brain fart. I wanted to do x==y but forgot you could do == on boolean values. Why? No idea. So I used ! xor.
|
# ? Jan 8, 2009 22:32 |
|
hexadecimal posted:I honestly don't know. I had a brain fart. I wanted to do x==y but forgot you could do == on boolean values. Why? No idea. So I used ! xor. You are crazy. How can you forget the standard idiomatic way to do something so fundamental as comparing for equality and end up with the rubegoldberg-esque xor contraption?
|
# ? Jan 8, 2009 22:46 |
|
I'm starting to think hexadecimal is some kind of 'worst programmer ever' gimmick account.
|
# ? Jan 8, 2009 22:54 |
|
hexadecimal posted:My WTF is really because I have trouble reading my own code, which is not good. Probably should never use 3 ternary operators on same line. Probably? quote:drat I suck.
|
# ? Jan 8, 2009 23:23 |
|
tripwire posted:You are crazy. How can you forget the standard idiomatic way to do something so fundamental as comparing for equality and end up with the rubegoldberg-esque xor contraption? I was really high at the time and was thinking of truth tables instead of normal comparison. I was trying to think of a way to sort the way I did in one line. I am special hexadecimal fucked around with this message at 00:02 on Jan 9, 2009 |
# ? Jan 8, 2009 23:41 |
|
hexadecimal posted:I was really high at the time and was thinking of truth tables instead of normal comparison. I was trying to think of a way to sort the way I did in one line. That's really the only explanation that makes any sense.
|
# ? Jan 9, 2009 00:31 |
|
hexadecimal posted:I was really high at the time and was thinking of truth tables instead of normal comparison. I was trying to think of a way to sort the way I did in one line. Are you high now?
|
# ? Jan 9, 2009 00:31 |
|
High as gently caress
|
# ? Jan 9, 2009 01:42 |
|
Mustach posted:High as gently caress The Something Awful Forums > Discussion > Serious Hardware / Software Crap > The Cavern of COBOL: if (!(hexadecimal ^ high)) { ++posts; }
|
# ? Jan 9, 2009 01:49 |
|
Dude, you just pre-incremented in order to increment the post! It seems like a post-increment would have been better suited! edit: Wow, that really wasn't funny, in retrospect. spiritual bypass fucked around with this message at 02:09 on Jan 9, 2009 |
# ? Jan 9, 2009 02:03 |
|
royallthefourth posted:Dude, you just pre-incremented in order to increment the post! It seems like a post-increment would have been better suited! I've got a solution for that
|
# ? Jan 9, 2009 02:23 |
|
royallthefourth posted:Dude, you just pre-incremented in order to increment the post! It seems like a post-increment would have been better suited! With complex object types, which post almost certainly is, as ++post implies all the tasks of logging in, finding a thread, writing a reply, etc., the pre-increment is more efficient that the post-increment, which tends to make useless copies of the object that most compilers are unable to optimize away.
|
# ? Jan 9, 2009 02:29 |
|
Scaevolus posted:With complex object types, which post almost certainly is Let's not get too full of ourselves here, ok?
|
# ? Jan 9, 2009 02:31 |
|
Scaevolus posted:which tends to make useless copies of the object that most compilers are unable to optimize away. Is that like what happens with Quote != Edit?
|
# ? Jan 9, 2009 02:48 |
|
zergstain posted:Unless your PHP was compiled without mysqli. And does that poo poo work with a 4.0.27 server? quote:Support for PHP 4 has been discontinued since 2007-12-31. Please consider upgrading to PHP 5.2. The release below is the last PHP 4 release. Why are you still using dead software?
|
# ? Jan 9, 2009 03:13 |
|
We have a few servers still running PHP4 because the clients are not going to pay to rewrite it in PHP5. It's fun when they want small things done because none of us have PHP4 development environments. Working off production
|
# ? Jan 9, 2009 03:20 |
|
PnP Bios posted:Why are you still using dead software? MySQL 4.0.27, we got PHP 5.2.6. MySQL 4.0 is also dead though, and it took me virtually no effort to get my boss to make a todo to talk to the server admin about upgrading the servers. That was a few weeks ago, no idea if or when it'll actually happen. To rephrase my original question: Can you use prepared statements with a MySQL 4.0 server? Oh, and exactly how long is the history of vulnerabilities in mysql_real_escape_string()? More than 2 or 3?
|
# ? Jan 9, 2009 03:27 |
|
zergstain posted:MySQL 4.0.27, we got PHP 5.2.6. MySQL 4.0 is also dead though, and it took me virtually no effort to get my boss to make a todo to talk to the server admin about upgrading the servers. That was a few weeks ago, no idea if or when it'll actually happen. Ah, my mistake. It shouldn't matter what version of mysql you are using. The mysqli module is does roughly the same thing, just faster and more secure.
|
# ? Jan 9, 2009 05:57 |
|
PnP Bios posted:Ah, my mistake. It shouldn't matter what version of mysql you are using. The mysqli module is does roughly the same thing, just faster and more secure. http://dev.mysql.com/tech-resources/articles/4.1/prepared-statements.html, the first loving Google result for 'mysql prepared statements' posted:Server-side prepared statements are an exciting new feature in MySQL 4.1. In this article, I will explain what, why, when, and how to use prepared statements.
|
# ? Jan 9, 2009 06:14 |
|
geetee posted:I think you should definitely propose it, but expect to be defined. I always feel so when I maintain an application someone else developed and I see all the user's passwords in plain text. It feels awfully dirty. I asked one of the seniors about it, our users are apparently so stupid that if we don't just fetch the password from the database and email it to them when they click the "Forgot Password" thing, they won't come back. zergstain fucked around with this message at 04:02 on Jan 10, 2009 |
# ? Jan 9, 2009 22:52 |
|
Well, it's better than one site I went to where the "save password" option sent your raw password as the "value" attribute in an HTML password field. For some reason it didn't do the same for the username.
|
# ? Jan 9, 2009 23:02 |
|
As opposed to sending a cookie with a secret key in it?
|
# ? Jan 9, 2009 23:16 |
|
zergstain posted:As opposed to sending a cookie with a secret key in it? Usually you want to encrypt the password client-side before you send it. Then it doesn't matter much how you send it to the server. (as long as encryption is good enough). vvvvvvvvvvv Yea I meant to also include hash functions, which are just one way encryption (or supposed to be ideally). hexadecimal fucked around with this message at 23:52 on Jan 9, 2009 |
# ? Jan 9, 2009 23:40 |
|
hexadecimal posted:Usually you want to encrypt the password client-side before you send it. Then it doesn't matter much how you send it to the server. (as long as encryption is good enough).
|
# ? Jan 9, 2009 23:48 |
|
zergstain posted:As opposed to sending a cookie with a secret key in it? Or something like that. Usually when you tick "remember my password" it just signs you in automatically but with this method you had to sign in manually. I mean there's still potential security issues with using magic cookies, but at least in most cases, you can only use that cookie to sign into that particular site, not to actually get a user's raw password and use it everywhere.
|
# ? Jan 9, 2009 23:54 |
|
Avenging Dentist posted:Or something like that. Usually when you tick "remember my password" it just signs you in automatically but with this method you had to sign in manually. I mean there's still potential security issues with using magic cookies, but at least in most cases, you can only use that cookie to sign into that particular site, not to actually get a user's raw password and use it everywhere. code:
Oh, and hexadecimal, if the client computes the hash, and you get to the hashes, you can just send the hash and login. If it's too sensitive to send the password as plaintext, use SSL. zergstain fucked around with this message at 04:10 on Jan 10, 2009 |
# ? Jan 10, 2009 04:05 |
|
zergstain posted:Oh, and hexadecimal, if the client computes the hash, and you get to the hashes, you can just send the hash and login. If it's too sensitive to send the password as plaintext, use SSL. Wouldn't something like this work? I remember doing it like this a long time ago. In case it's not obvious I don't code much in PHP or JS. php:<?php $key = rand(); //probably use something better $_SESSION["key"] = $key; echo '...<input type="password" name="password"><input type="hidden" name="key" value="'+$key+'">...'; ?> code:
php:<?php $password_hash = //get from database $key = $_SESSION["key"]; if(md5($password_hash+$key) == $_POST["password_hash"]) { echo "Yay, yuou're logged in!"; } ?>
|
# ? Jan 10, 2009 06:17 |
|
ryanmfw posted:Wouldn't something like this work? I remember doing it like this a long time ago. In case it's not obvious I don't code much in PHP or JS.
|
# ? Jan 10, 2009 06:24 |
|
ryanmfw posted:Wouldn't something like this work? I remember doing it like this a long time ago. In case it's not obvious I don't code much in PHP or JS. That doesn't really look like it could help much, I think it would be possible to edit the html and js so you could just paste the stolen hash and click login, and keep it so the session cookie would be valid.
|
# ? Jan 10, 2009 06:51 |
|
Isn't it possible to break md5 relatively easily nowadays?
|
# ? Jan 10, 2009 06:52 |
|
PnP Bios posted:Why are you still using dead software? Microsoft posted:Non-Supported Phase
|
# ? Jan 10, 2009 07:10 |
|
hexadecimal posted:Isn't it possible to break md5 relatively easily nowadays? (There have been a few exploits surrounding it but you can't just 'crack md5')
|
# ? Jan 10, 2009 08:17 |
|
zergstain posted:That doesn't really look like it could help much, I think it would be possible to edit the html and js so you could just paste the stolen hash and click login, and keep it so the session cookie would be valid. $_SESSION["key"] would be changed each time the login form is generated. I'm sorry if that wasn't clear. You don't even have to use sessions, I was just doing it as an example. And yes, MD5 is weak, SHA-1 or SHA-2 would be better, I just recall seeing a JS implementation of MD5 years ago. Would it be possible to break it in this instance? Possibly, if you could intercept the hash as it was being transmitted to the client. ohgodwhat fucked around with this message at 08:21 on Jan 10, 2009 |
# ? Jan 10, 2009 08:19 |
|
nebby posted:No, but its days are numbered. I recall reading a paper on how to generate strings, or documents that generate a given md5 hash.
|
# ? Jan 10, 2009 08:33 |
|
hexadecimal posted:I recall reading a paper on how to generate strings, or documents that generate a given md5 hash. Edit: Not sure, but I think it's basically "we can find two colliding documents" not so much "give us a document, we'll find a colliding one for it." You can use the former to exploit systems, but I think if you use salts and so on you're still theoretically in decent shape right now with MD5. But generally speaking it's probably a matter of time until someone comes up with a generic solution. And yes, I wikipedia'ed it! nebby fucked around with this message at 08:40 on Jan 10, 2009 |
# ? Jan 10, 2009 08:36 |
|
nebby posted:I'll admit I'm naive here, but I think the weakness of MD5 is a little more constrained than that at this point. Maybe someone who knows more about it can chime in, but I thought the general state of MD5 is "if you're using it today it's not quite an open door yet, but you should think about migrating" not "oh poo poo everyone who has MD5 hashes in their database is hosed!" At present, MD5 is only publicly known to be subject to an extremely easy collision generator attack. This attack is very fast and bodes very poorly for the health of the algorithm; it would not be beyond belief for governmental bodies to already have stronger attacks. There are real-world applications for which MD5 is currently completely compromised by the present attacks (third-party signatures being an incredibly relevant example, see recent X.509 CA shenanigans), but traditional first-party signatures and password hashes are not known to be broken. It is probably best for everyone to migrate away from MD5 for security purposes at this point.
|
# ? Jan 10, 2009 08:44 |
|
nebby posted:I'll admit I'm naive here, but I think the weakness of MD5 is a little more constrained than that at this point. Maybe someone who knows more about it can chime in, but I thought the general state of MD5 is "if you're using it today it's not quite an open door yet, but you should think about migrating" not "oh poo poo everyone who has MD5 hashes in their database is hosed!" check it out, these 4 all have the same MD5 hash: http://dl.getdropbox.com/u/67189/final1.ps http://dl.getdropbox.com/u/67189/final2.ps http://dl.getdropbox.com/u/67189/final3.ps http://dl.getdropbox.com/u/67189/final4.ps But yeah, the strong collision resistance is broken, but as far as I know, the weak collision resistance (given a message, it is hard to create another message such that their hashes are equal) and pre-image resistance (given a hash it is hard to find a message with that has) are still mostly okay for now. (with the above caveats mentioned by nebby)
|
# ? Jan 10, 2009 09:19 |
|
ShoulderDaemon posted:There are real-world applications for which MD5 is currently completely compromised by the present attacks (third-party signatures being an incredibly relevant example, see recent X.509 CA shenanigans). Everyone should have stopped using md5 about 4 years ago.
|
# ? Jan 10, 2009 13:55 |
|
|
# ? Jun 3, 2024 23:46 |
|
ryanmfw posted:$_SESSION["key"] would be changed each time the login form is generated. I'm sorry if that wasn't clear. You don't even have to use sessions, I was just doing it as an example. I have some web developer extension at work, and it looked like I could edit the html in RAM with it. But actually, I'm not sure what's stopping the hacker from saving the relevant stuff to disk since I believe when you submit the form and the browser requests the action url, the cookies for that domain would be sent. As long as the form wasn't reloaded from the server, the key would still be valid. Edit: Oh wait, a referrer check could stop that saving it to disk and editing it method. Probably wouldn't do anything for the use a Firefox extension and edit it in RAM method though. zergstain fucked around with this message at 19:32 on Jan 10, 2009 |
# ? Jan 10, 2009 18:57 |