|
Jesus loving christ.
|
# ? Mar 5, 2013 18:37 |
|
|
# ? May 17, 2024 20:26 |
|
Zombywuf posted:Nah, the point is that you leave the number of rounds open-ended, you can set it based on the amount of time between the user typing their password the first time and clicking the "Save Password" button. Makes life really hard for brute forcers as there's no definite "this is the wrong password" result. There is a name for the scheme and I can't remember what it's called. Halting key derivation functions? http://ai.stanford.edu/~xb/security07/index.html DaTroof fucked around with this message at 18:59 on Mar 5, 2013 |
# ? Mar 5, 2013 18:56 |
|
Zombywuf posted:Nope, not that. You're missing the point about it being open ended time-wise. You can use whatever iteration system you want, I would recommend that you do use bcrypt. That bit of code I dumped is not meant to be something you copy and paste into your app. The entire point of the system is to make hashes that depend on human time scales, and get more secure storage by the user simply waiting a few seconds. Obviously you need to use a secure password hash iteration system to do it. What happens when an attacker submits dozens or hundreds of passwords to this system at once? Does it mean any legitimate users at the same time end up with less-stretched hashes because there are fewer clock cycles per wall clock second? Do legitimate users trying to log in fail because their old hash lies beyond the wrong-password expiration time?
|
# ? Mar 5, 2013 19:10 |
|
Zombywuf posted:Nope, not that. You're missing the point about it being open ended time-wise. You can use whatever iteration system you want, I would recommend that you do use bcrypt. That bit of code I dumped is not meant to be something you copy and paste into your app. The entire point of the system is to make hashes that depend on human time scales, and get more secure storage by the user simply waiting a few seconds. Obviously you need to use a secure password hash iteration system to do it. Then basically all you're advocating here is dynamically changing the work factor for bcrypt so it takes a second on whatever server you're running on...which is way more work than just knocking that number up every year or so. Regardless, the "human second" only exists in how long your particular hardware takes to do whatever hashing you're talking about. The UberHasherBox 8000 attacking your leaked database will probably be doing the operations way faster. The idea of having the hash run for an actual second also means that passwords hashed while the server is under heavy load will be hashed more weakly so Jabor posted:Coding horrors: The horror is coming from inside the thread
|
# ? Mar 5, 2013 19:10 |
|
I can't believe what I'm reading. Jesus Christ.
|
# ? Mar 5, 2013 19:45 |
|
DaTroof posted:Halting key derivation functions? http://ai.stanford.edu/~xb/security07/index.html That looks like it. Cocoa Crispies posted:What happens when an attacker submits dozens or hundreds of passwords to this system at once? Does it mean any legitimate users at the same time end up with less-stretched hashes because there are fewer clock cycles per wall clock second? Do legitimate users trying to log in fail because their old hash lies beyond the wrong-password expiration time? That's just a good old dos, assuming timeouts anyone can simply swamp the login server and any system that makes hashes harder to compute will only make this worse.
|
# ? Mar 5, 2013 19:47 |
|
Zombywuf posted:That looks like it. No the point of that question is that the submitting a bunch of new logins is a preflight attack to the main attack. At some prior time you perform a near-ddos level of new account creation using your botnet, thus any REAL accounts created during that time get a lot less CPU time in relation to Wall time, meaning those hashes are MUCH weaker than normal. Then the main attack acquires the passwords including these much weaker ones. In short, stop trying to outsmart scrypt. It's right.
|
# ? Mar 5, 2013 19:54 |
|
https://www.facebook.com/notes/facebook-engineering/under-the-hood-dalvik-patch-for-facebook-for-android/10151345597798920 Facebook for Android modifies the VM it runs in on older Android versions to allow it to work even with a 65k method limit Dalvik restricts apps to (65k according to this bug report: https://code.google.com/p/android/issues/detail?id=20814). Wow.
|
# ? Mar 5, 2013 20:37 |
|
HKDF might make sense for a system that is already tightly controlled, where anyone using it has training and has otherwise been granted access to this based on merits, accountability, etc. Stuff like multi-factor auth is already in play and anyone with a login understands to take it seriously and it's unlikely they're gonna have a DB leak. Doing this on a consumer grade site like Linkedin or banks or whatever I'd be worried about the amount of trust you're putting into users (read: the general public at large), Unless you put an upper limit on t you're bound to have some clueless % of your userbase getting lost on the password setup and continually spiking the hell out of your system every time they log in. Educating the majority is a task enough, but some people are incorrigible. Put large flashing glittery instructions in a huge font about what they're supposed to do, and those people are going to sit at that page for 30 seconds, wonder what it's doing, go back to facebook, get some coffee, and maybe 20 minutes after that they'll revisit the page and go "Well it's got to be done now, I guess I'll click finish?". I guess the upside is they'll stop going to your site after, say, the first login Even if you put say a 5 second limit on t, IMO you're still taking the "make the hashing expensive" to an extreme at the expense of your own server stability (or server costs if you're smart and purchase extra hardware to farm out all the HKDF tasks so that the post-login experience doesn't suffer) , user experience (you'd have to be a UE supergenius to make this have trivial impact on things like conversion, retention...), and don't forget power bills when you're pegging CPUs this regularly. It only makes sense in special scenarios like an internal company site where anyone with access to it is an employee or partner and you have a large amount of control over its users and its usage. Bhaal fucked around with this message at 20:51 on Mar 5, 2013 |
# ? Mar 5, 2013 20:43 |
|
Glimm posted:Facebook for Android modifies the VM it runs in on older Android versions to allow it to work even with a 65k method limit Dalvik restricts apps to (65k according to this bug report:
|
# ? Mar 5, 2013 21:18 |
|
teamdest posted:No the point of that question is that the submitting a bunch of new logins is a preflight attack to the main attack. At some prior time you perform a near-ddos level of new account creation using your botnet, thus any REAL accounts created during that time get a lot less CPU time in relation to Wall time, meaning those hashes are MUCH weaker than normal. Then the main attack acquires the passwords including these much weaker ones. quote:In short, stop trying to outsmart scrypt. It's right. Take it up with the authors. Bhaal posted:I guess the upside is they'll stop going to your site after, say, the first login This is an added bonus I hadn't considered.
|
# ? Mar 5, 2013 21:21 |
Zombywuf posted:So hash on the client. Replay attacks?
|
|
# ? Mar 5, 2013 21:22 |
|
nielsm posted:Replay attacks? SSL?
|
# ? Mar 5, 2013 21:23 |
|
Zombywuf posted:So hash on the client. A malicious client will just send you the hash from the DB. The way password hashing prevents that is by making the process of obtaining useful credential from a database dump computationally infeasible (or at least very difficult). There's no way of doing that, that doesn't also require the authentication agent (server) do something that's computationally "challenging".
|
# ? Mar 5, 2013 21:30 |
|
ExcessBLarg! posted:If the whole point of hashing passwords is so that someone who obtains a database dump can't obtain useful credentials from it, then how does pushing the crypto work onto untrusted clients help at all? Lol yeah, let's just pretend I didn't say that bit.
|
# ? Mar 5, 2013 21:33 |
|
The Gripper posted:Definitely, I only mentioned it because that specific case (trying to find a user with the password "abc123" when you know that user exists) isn't one where a per-user salt really shines, an attacker could perform the attack in short order either way. How?
|
# ? Mar 5, 2013 22:04 |
|
This thread is dangerously close to becoming self-referential.
|
# ? Mar 5, 2013 22:12 |
|
This thread is on time-out while you think about what you did wrong.
|
# ? Mar 5, 2013 22:18 |
|
Coming back to coding horrors (I hope that was what we did wrong ): The other day I was tasked to look at a 2 character input field of a form (think 'en'/'de'/'fr'/...) . Users reported that the field behaved weirdly and was hard to edit. Well, how would you make an html input field accept only 2 characters? Well obviously you would use a standard input field and write a bit of javascript that reacts on keydown and on change, monitors keystrokes and only accepts backspace once 2 characters are in the field. Sereri fucked around with this message at 12:18 on Mar 6, 2013 |
# ? Mar 6, 2013 11:58 |
|
Not exactly a coding horror, but the IMAP rfc deserves to be here:rfc3501 6.3.8 posted:An empty ("" string) mailbox name argument is a special request to The path delimiter in IMAP is implementation defined and has to be fetched with a special empty LIST command on each connection to the server. Assuming the server supports paths which it might not. IMAP servers can also support namespaces, which are not paths.
|
# ? Mar 6, 2013 12:10 |
|
What possible reason could there be to have an implementation-defined path separator?
|
# ? Mar 6, 2013 12:38 |
|
pokeyman posted:What possible reason could there be to have an implementation-defined path separator? A logical guess would be an implementation storing individual mailboxes as separate files, and then you'd obviously want to use the same path separator as the underlying file system. I'm pretty sure this was from before the days before anyone had any idea what this "security" thing was or why it was important.
|
# ? Mar 6, 2013 12:56 |
|
Jabor posted:A logical guess would be an implementation storing individual mailboxes as separate files, and then you'd obviously want to use the same path separator as the underlying file system. You'd think the benefit of using your system's native path separator gets undone by dealing with the additional protocol complexity. Maybe this is why I don't write RFCs.
|
# ? Mar 6, 2013 13:18 |
|
pokeyman posted:You'd think the benefit of using your system's native path separator gets undone by dealing with the additional protocol complexity. Maybe this is why I don't write RFCs. Sure, but that complexity is on the client end. A more charitable explanation would be that people had already built implementations with different path separators, and the standardization group went for a compromise that meant that no-one would have to change anything.
|
# ? Mar 6, 2013 13:29 |
|
Tumblr ask box messages have the following restrictions: they must be 500 characters or less, they can't contain links, and they cannot contain newlines. The first two are presumably anti-spam measures (though they're fairly annoying) and are enforced both with client-side javascript and serverside; if you disable the javascript handlers that cut you off, the message just gets silently dropped. Hilariously, they will also drop messages like 'foo...bar' silently or no good reason. The last one is only enforced client side. If you disable the Javascript interval that trims newlines, you can submit them just fine. It's awful.
|
# ? Mar 6, 2013 21:37 |
|
Done with table mountain for now but there's plenty more horror in the main site. The first thing I see is hundreds upon hundreds of raw .html files in the main dir, each with 300 lines of identical horrendous code for the header alone. I don't even know where to begin. A choice one from the 300, all on one line: code:
Clavius fucked around with this message at 01:36 on Mar 7, 2013 |
# ? Mar 7, 2013 01:34 |
|
Constantly finding surprises from previous developers. Today I found a script that has the following sequence:code:
|
# ? Mar 7, 2013 03:54 |
|
The hell kind of language has "elsif"?
|
# ? Mar 7, 2013 04:05 |
|
Perl and Ruby. Python one-ups both with 'elif'.
|
# ? Mar 7, 2013 04:19 |
|
Suspicious Dish posted:The hell kind of language has "elsif"? There's #elif in the C and C++ preprocessor.
|
# ? Mar 7, 2013 04:20 |
|
Also Ruby.
|
# ? Mar 7, 2013 04:20 |
|
That Turkey Story posted:There's #elif in the C and C++ preprocessor. I asked about "elsif". Apparently it's Perl.
|
# ? Mar 7, 2013 05:00 |
|
Yeah, it's Perl. Most of the applications developed in house were written in Perl, usually as a proof of concept that somehow found its way into production.
|
# ? Mar 7, 2013 06:16 |
|
So the assignments instead of equality tests notwithstanding, either they're not using strict mode, or they named a sub "z" elsewhere and so it didn't barf on "!z" when they meant "!$z." I am assuming the former but everything else in there makes me think the latter isn't out of the question either
|
# ? Mar 7, 2013 06:18 |
|
Ephphatha posted:usually as a proof of concept that somehow found its way into production. The story of so many things.... No wait, don't seriously ship that, it's....aww
|
# ? Mar 7, 2013 07:36 |
|
Always assume it will go into production, because it almost always will.
|
# ? Mar 7, 2013 09:03 |
|
kitten smoothie posted:So the assignments instead of equality tests notwithstanding, either they're not using strict mode, or they named a sub "z" elsewhere and so it didn't barf on "!z" when they meant "!$z." I am assuming the former but everything else in there makes me think the latter isn't out of the question either Ahh gently caress, that's me spending too much time debugging lovely SQR forms. And yeah, I'm not sure what's going on with the operations since the inner if/elses could easily be ommitted (since one of x, y, or z will always be true) or rewritten to check if ($z or $x or $y). There's no standards for coding style so code is a mix of 'use Module' and 'require "module.pm"' (all usually declared at the top of the file thankfully) with some files using a BEGIN {} block, some defining a sub main procedure, and some just defining a set of instructions before the subs are declared with no special marker (a great example of this is a 800 line file with a 100 line header and all of 5 lines of code between it and the procedures). Edit: use strict seems to be included in (some) code written after 2007. -w is almost never used. ephphatha fucked around with this message at 09:58 on Mar 7, 2013 |
# ? Mar 7, 2013 09:56 |
|
I saw an ad on my site essentially doing the following:code:
|
# ? Mar 7, 2013 10:55 |
|
Fuoco posted:I saw an ad on my site essentially doing the following: From the outside it looks silly, but it's probably a combination of AdServer: code:
Ad ingestion: code:
Awful app is making it impossible to output & lt; without spaces. Even tried replacing & with & amp; Volmarias fucked around with this message at 16:51 on Mar 7, 2013 |
# ? Mar 7, 2013 16:48 |
|
|
# ? May 17, 2024 20:26 |
|
Suspicious Dish posted:The hell kind of language has "elsif"?
|
# ? Mar 8, 2013 04:45 |