|
qntm posted:the track record of reliability that those programs have proved themselves to have (a level of reliability which any replacement program would have to match) this just shows how far we've come in 40 years of software engineering. similarly old editors like vi and emacs being popular show that we haven't really progressed in terms of interface either.
|
#
?
Dec 14, 2010 23:54
|
|
|
|
| # ? May 15, 2024 13:12 |
|
|
We've progressed - it's just that that the improvements you get from completely new techniques haven't managed to outpace the stability you get from the sheer amount of time these projects have had to accumulate bugfixes and incremental improvements. If you built vi now and gave it 34 years to mature I'm sure it would be much better then vi is now. Of course by then the old vi may have acquired mind reading powers or something.
|
|
#
?
Dec 15, 2010 00:10
|
|
|
tef posted:For what it is worth (not much), the talk that started this derail is online: http://vimeo.com/17675268 I really liked your talk! It was funny how many people in the audience were irked by your slagging on drupal 
|
|
#
?
Dec 15, 2010 00:20
|
|
|
tef posted:this just shows how far we've come in 40 years of software engineering. Not really, it's just impossible for a computer program to demonstrate 40 years of continuous reliability under heavy load without having been written 40 years ago. There's plenty of code out there which was written "only" 20 years ago or 10 years ago and has done its job perfectly ever since and will continue to do so long into the future. If you want someone to replace your working but antiquated COBOL with something modern i.e. recently-made, then proving that any possible replacement can meet the task means testing it to breaking point and under NASA-level intensity and scrutiny. There is nothing to stop people writing programs right now, in modern languages, which will operate perfectly for the next 40 years. It happens all the time. The problems are (1) getting explicit requirements out of a program which was invariably programmed with a great deal of skill and subtlety but has little to no surviving documentation (those requirements could be met if they were clear), (2) proving that the replacement matches those requirements to the satisfaction of the person with the money and the severe disinclination to switch, and (3) making the switch seamlessly. We could do this. There's nothing stopping any of this happening, other than the fact that it's cheaper for the customer and more profitable for the provider for everybody to stick with what works.
|
|
#
?
Dec 15, 2010 01:03
|
|
|
tripwire posted:I really liked your talk! It was funny how many people in the audience were irked by your slagging on drupal Thanks, It was just one really vocal guy, we had a beer afterwards.
|
|
#
?
Dec 15, 2010 02:40
|
|
|
each password is salted with its first two characters
|
|
#
?
Dec 15, 2010 03:59
|
|
|
Janin posted:I'm honestly shocked that Perl runs at all on a EBCDIC platform Perl is there to help convert EBCDIC to more sane encodings. It's surprising how much Perl is used on big expensive machines.
|
|
#
?
Dec 15, 2010 04:03
|
|
|
tef posted:similarly old editors like vi and emacs being popular show that we haven't really progressed in terms of interface either. Not really. Newer software is easier to get up to speed on. Some may argue that nothing new is as fast to edit in as vi or emacs, but that's arguable and besides, it's a reasonable trade-off for many. In other words, I don't think your case is as airtight as you presume.
|
|
#
?
Dec 15, 2010 04:29
|
|
|
Oh god - it's like he works where I work except nobody here ever heard of a salt before I was hired.
|
|
#
?
Dec 15, 2010 18:26
|
|
|
Lord Rumples Catte posted:Tiny Bug Child posted:that chart made me curious enough to go see what the most popular passwords for our sites are and a bunch of the same ones show up like "dragon" and "baseball" and "monkey" and "pepper" and "superman" Lord Rumples Catte posted:wait Tiny Bug Child posted:uhhh, i'm the lead web developer, graham. i have to be able to see the mysql database to do my job. I love web developers!
|
|
#
?
Dec 16, 2010 03:21
|
|
|
I
|
|
#
?
Dec 16, 2010 15:11
|
|
|
qntm posted:We have that kind of scenario where I work, but the problem is our Perl needs to be run on about 65 different machines all running different operating systems. "Getting a module from CPAN" becomes such a tall order that if something isn't included in every Perl installation by default, rolling your own or figuring out how to do without it almost always ends up being quicker and easier. Yeah, that is a pretty extreme case, and it's hard to fault Perl too much for being kludgey at times, it is such a down-in-the-trenches language to begin with (I mean that in a good way). In my scenario, however, the code was running on a handful of well-supported OS, and the work the modules was doing was central to the script's function. The guy who had written the code in the first place was mostly a C programmer, and if he couldn't figure out how do to something in the C idiom, he'd drop in system() calls and backticks as needed (which isn't the most portable code either). To be fair, the code worked reliably and that's what matters. It was just such a textbook example of a really smart guy whose intelligence starts to calcify to stubbornness and arrogance at the edges. I did manage to eventually sell him on the value of hashes and regexps at least.
|
|
#
?
Dec 16, 2010 15:36
|
|
|
mr_jim posted:I In Real Life
|
|
#
?
Dec 16, 2010 16:19
|
|
|
Honestly if you program C for long every other language just seems like cheating. It kind of takes a mental shift to let the compiler/interpreter/library handle things without having this nagging feeling that the whole thing is going to explode.
|
|
#
?
Dec 16, 2010 16:25
|
|
|
Oh sure, and I think every programmer has a phase they go through where they must fight the temptation to reinvent the wheel. This is especially true for anybody who learned to code in the 70s or 80s, when getting performance out of the bare metal was still so important that readable, well-designed code barely entered the equation.
|
|
#
?
Dec 16, 2010 17:09
|
|
|
Kelson posted:I love web developers! to be fair if you have access to the DB, it's not hard to see this. Type in the passwords you want to look for and concatenate them with their salt. If rows match, you know that password is used.
|
|
#
?
Dec 17, 2010 13:07
|
|
|
MononcQc posted:to be fair if you have access to the DB, it's not hard to see this. Type in the passwords you want to look for and concatenate them with their salt. If rows match, you know that password is used.
|
|
#
?
Dec 17, 2010 13:33
|
|
|
MononcQc posted:to be fair if you have access to the DB, it's not hard to see this. Type in the passwords you want to look for and concatenate them with their salt. If rows match, you know that password is used. But even this would be defeated with md5($username . $password . $global_salt). You could still loop through all users, but you couldn't just do a "select count(*) from users where pw_hash = md5("qwerty" . $global_salt)"
|
|
#
?
Dec 17, 2010 13:46
|
|
|
Wheany posted:But even this would be defeated with md5($username . $password . $global_salt). You absolutely could if your hashing function exists as part of your DB engine. Knowing this is about a horror thread, I'd be ready to bet it's MD5 in MySQL. SELECT * FROM `users` WHERE `password`=MD5(CONCAT(`username`,"SomePassword","global salt")); Salts don't really stop you from brute-forcing passwords like that. Afaik they're mostly useful to stop someone from making a single rainbow table to scan over the whole DB in one go to grab all passwords and instead force intruders to generate the equivalent of one rainbow table per user. This is why salts should be unique per password per user. Correct me if I'm wrong.
|
|
#
?
Dec 17, 2010 14:02
|
|
|
And some people recommend iterating the hash function multiple times so that an attack on an individual password would be too costly.
|
|
#
?
Dec 17, 2010 16:26
|
|
|
MononcQc posted:to be fair if you have access to the DB, it's not hard to see this. Type in the passwords you want to look for and concatenate them with their salt. If rows match, you know that password is used. It's more likely they just store them in plain text, which is probably more common than you'd think given the number of piles of lovely PHP that were created in the last 10 years. Many of them were probably wrapped in something pretty and secure-looking and left alone otherwise.
|
|
#
?
Dec 17, 2010 16:44
|
|
|
Munkeymon posted:It's more likely they just store them in plain text, which is probably more common than you'd think given the number of piles of lovely PHP that were created in the last 10 years. Many of them were probably wrapped in something pretty and secure-looking and left alone otherwise. He does mention earlier in that thread that their passwords are hashed (they pick the first two letter as a salt) and do not have clear text versions of them. I assumed they didn't store them in plain text but some other posts make it kind of ambiguous in the original thread. But yes, I am absolutely not surprised by the idea of having dozen of sites keeping stuff in clear text or yet just MD5'ing it and calling it 'encryption'. I've seen pretty retarded stuff, some of which I've documented in a blog post. Basically, corporation handling healthcare-related data wouldn't even put any check on the data available (accessible with auto-incrementing IDs). When called out on it, they 'encrypted it' with base64. When called out on that, they decided to drop all the data because it was too hard to do. They then called the product a complete success. And they also threatened to sue us in the process. Not mentioned in the blog post is how a coworker of mine found an SQL injection that worked, managed to get the admin password to the DB (whose server was accessible to everyone) and could access databases of dozens and dozens of customers' tables, all on the same database, with sensitive information such as their client lists and whatnot. MononcQc fucked around with this message at 17:28 on Dec 17, 2010 |
|
#
?
Dec 17, 2010 17:21
|
|
|
Thanks for making me feel better about the (relative) security of the place I work - that doesn't happen often.
|
|
#
?
Dec 17, 2010 17:39
|
|
|
Munkeymon posted:Thanks for making me feel better about the (relative) security of the place I work - that doesn't happen often. To be fair, my old job had to be second to Tiny Bug Child's job in terms of retarded security decisions. In the two years and a half I was there we significantly made things better, but a lot was left to do. Here's a short list of what I can name off the top of my head:
The team and I (we were 4) fixed most of these bugs in the 2.5 years I spent there, including closing most security holes, separating dev from prod (a massive undertaking with millhundreds of thousands of lines of PHP code), documenting all insane stuff and sending it to management, etc. This software was mostly 10 years old PHP and there is a whole lot more crap I haven't even mentioned that was as bad or retarded. I've not even touched architecture and infrastructure decisions. My final days there were spent reviewing over 900 MySQL queries and sanitizing the poo poo out of them, right after having introduced a token system to remove CSRF holes. I like to believe I made the site tolerable rather than a complete horror. One week after I left, they decided to build a second system to replace it. I can say I've learned a whole drat lot during that time, mostly about how not to do things. I can easily detect some code smells months or years before they get problematic, which gets pretty useful. Probably explains my love of Erlang for maintainable software that was well thought-out. tl;dr I've seen web development hell and tried to fix it. I quit. MononcQc fucked around with this message at 18:05 on Dec 17, 2010 |
|
#
?
Dec 17, 2010 18:00
|
|
|
My first job fresh out of uni I was given root access to all our customers databases on the second day (i.e shown the page on the internal wiki where all the login details were stored). This was a lot of data.
|
|
#
?
Dec 17, 2010 18:13
|
|
|
MononcQc posted:
I hope this makes you feel at least a little better about your old job: http://forums.somethingawful.com/showthread.php?threadid=2803713&userid=40673&perpage=40&pagenumber=2#post372379389
|
|
#
?
Dec 17, 2010 19:07
|
|
|
Munkeymon posted:I hope this makes you feel at least a little better about your old job: http://forums.somethingawful.com/showthread.php?threadid=2803713&userid=40673&perpage=40&pagenumber=2#post372379389 Haha, oh man. This forum could run its own thedailywtf.com.
|
|
#
?
Dec 17, 2010 19:21
|
|
|
code:
|
|
#
?
Dec 17, 2010 20:26
|
|
|
MononcQc posted:Correct me if I'm wrong.  I'm pretty paranoid when it comes to security, cryptography and such, but I know I'm not a security expert. I've probably made some insecure software in my time, but at least if someone informed me of my insecure service, I'd a) poo poo my pants, b) try my loving best to secure it. I probably wouldn't talk about "the peasants accounts", even ironically.. e: MononcQc posted:SELECT * FROM `users` WHERE `password`=MD5(CONCAT(`username`,"SomePassword","global salt")); poo poo, and this works.  It might take a while for any site with a significant number of users, but I guess I have to poo poo my pants now 
Wheany fucked around with this message at 21:06 on Dec 17, 2010 |
|
#
?
Dec 17, 2010 20:38
|
|
|
Wheany posted:poo poo, and this works. I'm not familiar with the performance of SQL Server's MD5 function, but "a while" is probably a few seconds. A high end nvidia card with a good CUDA md5 implementation can easily exceed one billion hashes per second.
|
|
#
?
Dec 17, 2010 21:52
|
|
|
Even without MySQL's MD5, you could nest queries, use cursors, accumulate data in increments wherever you want, etc. As Zhentar said, going with CUDA lets you be real fast. Then you could also rent some Amazon instances and work on it with a whole farm. If you're looking for a specific password, it's easy to verify if it's there or not for any user. Again, salts are not meant to make it hard to find a password or make it harder to brute force. They're only there to keep someone from coming in with a pre-generated table of MD5s and matching it against your table to find them real fast. Having good, strong passwords is still recommended to make the brute-force slow. The concept of salts is just to make it impractical, or at least slightly harder, to find all passwords for everyone at once. Better approaches include using slow hashes like bcrypt (I think that's the one at least), which basically let you decide how long it takes to hash the password. This lets you make hashing to check your users a bit longer. This is not bad for a login query because it can still be relatively short in the grand scheme of things, but for someone trying to brute-force the password, it's a question of adding a whole drat lot of time. I have not seen people using slow hashes or complaining about them yet, though. E: duplicated word MononcQc fucked around with this message at 22:31 on Dec 17, 2010 |
|
#
?
Dec 17, 2010 22:26
|
|
|
http://codahale.com/how-to-safely-store-a-password/
|
|
#
?
Dec 17, 2010 23:02
|
|
|
Wheany posted:But even this would be defeated with md5($username . $password . $global_salt). salts should be prefixes, not suffixes.
|
|
#
?
Dec 18, 2010 00:02
|
|
|
tef posted:salts should be prefixes, not suffixes. Mind telling us why?
|
|
#
?
Dec 18, 2010 02:21
|
|
|
Never mind me.
nielsm fucked around with this message at 02:35 on Dec 18, 2010 |
|
#
?
Dec 18, 2010 02:33
|
|
|
KARMA! posted:Mind telling us why? A simplified answer: For most hash constructions, you can amortize the costs of a changing suffix more readily than a changing prefix, meaning that you can take a dictionary of unsalted hashes for common passwords and cheaply transform it to a dictionary of suffix-salted hashes for common passwords, allowing more effective attacks against databases of accounts. Please note that this is a broad discussion of one particular class of attack, and there are a whole lot of caveats attached to this description which I'm not going to go into here. The answer you should keep in mind is more general: Cryptographic protocols are really incredibly hard to design well, and they tend to be extremely subtle and fragile, often for reasons that don't appear to make sense unless you have had extensive specialist education in the field. If you don't know exactly why every single decision was made in an existing protocol, you are not qualified to change the protocol. Please don't invent your own cryptographic protocols.
|
|
#
?
Dec 18, 2010 02:34
|
|
|
ShoulderDaemon posted:For most hash constructions, you can amortize the costs of a changing suffix more readily than a changing prefix, meaning that you can take a dictionary of unsalted hashes for common passwords and cheaply transform it to a dictionary of suffix-salted hashes for common passwords, allowing more effective attacks against databases of accounts. It looks to me like the username is taking the place of a nonconstant prefix.
|
|
#
?
Dec 18, 2010 03:25
|
|
|
Jabor posted:It looks to me like the username is taking the place of a nonconstant prefix. Oh, probably, but it's a goofy construction and usernames are lower-entropy and often longer than the random nonces you're supposed to use as salts which will have who-knows-what kind of effect on attackers trying to minimize costs because now they can potentially exploit having the whole first block of the hash being a combination of low-entropy terms; not to mention the possibility of collisions where user foo has password barqux and user foobar has password qux, which all means that the potential attack surface is larger in some really-hard-to-quantify manner. There's just no good reason for using a non-standard protocol which seems like it might have the same security properties as the real thing but hasn't been studied when you can just not write your own cryptographic protocols. Seriously, cryptographic protocols are really hard for lots of small, subtle, incredibly obscure reasons. It's very hard to get the education you need to be able to do a halfway-adequate job of reasoning about possible attacks, the education expires extremely quickly, and even the experts get it wrong a large proportion of the time. It can be fun to see if you can find all the problems in some homemade protocol, but even if you and your best friend and 5000 people on the internet think you found them all, you're simply wrong.
|
|
#
?
Dec 18, 2010 03:51
|
|
|
KARMA! posted:Mind telling us why? It depends on the hash, but most are built on the Merkle–Damgård http://en.wikipedia.org/wiki/Merkle%E2%80%93Damg%C3%A5rd_construction if A = abc and you know the hash of ab, the hash of abc is easy to compute. By comparison if you have A = abc and you know the hash of bc, the hash of abc is more work to compute. This is why I think authentication and passwords should be handled by frameworks entirely -- it is far, far too easy to break poo poo.
|
|
#
?
Dec 18, 2010 04:20
|
|
|
|
| # ? May 15, 2024 13:12 |
|
|
king_kilr posted:http://codahale.com/how-to-safely-store-a-password/ The thinking behind bcrypt's strengthening can be extended to the idea of halting password puzzles: I.e A correct password will halt the password checker, an invalid one will never terminate. Alternatively, you might enjoy a real authentication protocol: http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
|
|
#
?
Dec 18, 2010 04:29
|
|