1,020 karma · joined August 20, 2010
Huh. He kind of lost all credibility at that point. Breaking RSA isn't something you just decide to do. I'll wait for the day when he announces he's broken it.
Imagine you decide to fix buffer overflows by switching from C to Java. You're no longer relying on the fact that your code won't have buffer overflows, you're relying on the fact that (1) the JVM code doesn't have buffer overflows and (2) the JVM will catch all your buffer overflows and throw exceptions.
I feel very confident Java has few, if any, bugs. I do not, however, hold that same level of confidence with most APIs in use today. They simply haven't had the time to become as robust.
However, even then, this does not solve all of your issues. There are times when you need to insert tags dynamically, and once you start doing that, there are a million more ways things can go wrong. Sure, you can put another restrictive API in front of that which requires the programmer to take ten lines to describe the single tag she wants, but those APIs will rarely get used because of this.
At the end, for any class of vulnerabilities, there is always a way to entirely eliminate it. Rarely is it the case, however, that you can do so without dramatic losses in other areas.
Not really. There are many examples of sites which should be more concerned. Anything with your credit card information, say.
> Using a WAF and white listing parameters
Yeah, that's a good start. But you need to make sure everything goes through the white list, and that's the hard part.
> Just another reason why I keep the code internal.
What does this have to do with security?
I know that. I wrote "The fix is also very simple: "Check the bounds of your arrays before you use them"" in order to demonstrate that saying "Sanitize your input" is equally wrong.
Giving that advise is really, really easy. Every competent web developer knows that. The hard part is actually implementing it.
For example, lots of programs written today still have buffer overflow vulnerabilities. Those are even older. The fix is also very simple: "Check the bounds of your arrays before you use them". That is, again, just telling the developer to not make mistakes.
Designing security into your app can help with preventing XSS attacks, but there is no single perfect way.
Besides, xoring the other bits does nothing to increase the security on non-broken hashing functions. Take the extreme case of xoring every bit to generate either a 0 or a 1. You've put a lot of effort into generating that single bit, but it's no more random than if you just took the lsb of the hash.
> I could run it out to md5 and trim the first n chars but that’s not going to be very unique.
What? MD5 going to be orders of magnitude better than what he's given.
> Storing a truncated checksum in a unique field means that the frequency of collisions will increase geometrically as the number of unique keys for a base 62 encoded integer approaches 62^n.
Well, duh. That's a given. And his solution won't do any better.
> I’d rather do it right than code myself a timebomb.
Doing it right would be using a real hash. Not something you came up with over a cup of coffee.
> Pretty random-looking, huh?
If that's his idea of testing for randomness... Use any randomness test and I guarantee you MD5 will preform better and faster.
> This is a minimum security technique.
This is the best piece of advice in the whole piece. Please never ever use this for something you want to be secure. I haven't tried to break it (maybe I'll do that over the weekend), but giving it a first glance I would be willing to bet anyone with some skill would be able to do so.
"Anyone, no matter how unskilled, can design an algorithm that he himself cannot break." -- Bruce Schneier
If there is a proven theorem that something is impossible, either the theorem is wrong or it's impossible.
> the halting problem is solved routinely by people in software engineering research groups
I'm not sure how I'm meant to read this.
If it is that people do the solving of the halting problem (that is, people read the source of the program and say "this will halt" or "this will not halt"), then they have not solved the halting problem: the halting problem states there is no way to do this by algorithm.
If it is that people write software which solves the halting problem, then you are wrong, and you explain to yourself why you are wrong. They are solving a different problem, namely, whether some very small class of computable functions halts.
Your two sentences "the halting problem is solved routinely" (assuming you mean the latter case, as above) and "this does not invalidate the Halting Theorem" do not logically work.
> when really there is absolutely nothing wrong with hashing.
Hashing is millions of times better than storing the plaintext. Adding a salt probably increases the workload by about as much as going from salted hash to bcrypt [constant time lookup in rainbow table -> exponential time in length of password -> higher constant factor exponential time]. But I must disagree with you saying there's nothing wrong with hashing, however. There is something wrong with hashing, and that is that it's possible to brute force many passwords. However you're perfectly right that going hash+salt to bcrypt doesn't do nearly as much as going from plaintext to hash+salt.
And you're also right in that the simple passwords will fall anyways. You could have it take 30 seconds per password and an attacker could still get the passwords a couple percent of your users (who picked '123456', 'password', etc). If I pick '$yN3,A%2vq{-', no matter if the server is using MD5-crypt or even scrypt, you won't be getting my password.
> you're going to become CPU bound extremely quickly
This is one of the only valid criticisms of bcrypt, and it is a significant one. One of the nice things about it, though, is you don't have to use the 0.3 second time. That's just chosen arbitrarily. If you think that's too high, then go with 0.03 seconds, or 0.003 seconds. Surely you can deal with that requirement. Granted, brute forcing is now 1000 times faster -- but hey, it's 1000 times slower than bruteforcing a hash.
Anyhow, I don't disagree with most of what you're saying. I just wanted to point out that it's still possible to go with bcrypt by just decreasing the workload to a reasonable level for your application; I'm not trying to say you're wrong.
I knew the developers of the site were looking here. I knew there was nothing critical running on this site. They were asking for feedback. Given that, it is much easier to demonstrate the places where it should be fixed than to give instructions on how to recreate each attack.
Demo: http://profile.io/foobar
[EDIT] As someone else pointed out, viewing the list-of-developers page puts up the XSS, which is even worse. I didn't know that page existed.
[EDIT2] It turns out I broke a lot more than I tried to. I also own the account 'xss' which has an unclosed '<' inside of its name, and that destroys half the page. I'm really sorry, please delete that account.
[EDIT3] I broke that account even more in order to fix it. I had an unclosed script tag, so I closed it off in my 'location'. If you fix the xss in just the profile information, then the page will get messed up again.
[EDIT4] The 'test' account was deleted, but the XSS's haven't been fixed? Updated to point to a different page I had made.
But please don't rely on just escaping < and >. You have to worry about double-quotes too, I can end a string and add a "onload" or "onfocus" attribute if it's already in a tag. And sometimes you have to worry about single quotes. In fact, there's a lot to take a look at.
Instead of just fixing the case at hand, try to be proactive about it. Check to make sure you don't have anything else.
Edit: Click the search box, for example. http://www.pinkbike.com/forum/search/?q=%22%20onclick=%22ale...
http://www.pinkbike.com/news/search/?q=%3C%2Ftitle%3E%3Cscri...
http://www.pinkbike.com/product/compare/?items=466,%22%3E%3C...
http://www.pinkbike.com/photo/list/?date=all&text=%3C/ti...
http://www.pinkbike.com/buysell/list/?q=%3Cscript%3Ealert%28...
http://www.pinkbike.com/forum/search/?q=%3C/title%3E%3Cscrip...
Edit: I've stopped adding xss's. It's actually harder to find input boxes which don't lead to xss's than ones which do.
C++ templates are.
Check out this IOCCC entry which does simulate a Turing machine, but only by having another script repeatedly run it.
Edit: Yes, I meant to copy the link, see mchouza's comment for the link.
<title>IPad’s Rivals Can’t Beat It on Price - NYTimes.com</title>
Edit: The original comment said something like, and I don't have the exact quote, "The OP changed the title and introduced a mistake."
Couldn't you then, in that case, give each anonymous user a number, and say "Anonymous User 1"? On the other hand, given that it might be possible to reverse it to the user who made those upvotes.
I hope you're joking. Sometimes, sure, they're good. But that article is ... I'll hold my tongue. They're making it out to be some amazing feat. While I don't want to take away from the authors who I'm sure are great researchers, this is nothing new. And then there's the part where they suggest RSA fix it, and that's just something else.
Here's a valid title:
"></title></head><body onclick="a" ondblclick="a" onload="alert(1)" onmousedown="a" onmousemove="_onmousemove_" onmouseout="a" onmouseover="asdf" onmouseup="a" onkeydown="a" onkeypress="a" onkeyup="a" onunload="a">
The other stuff is just there to mess up your filter. Just escape <, >, ", and '. And then test it to make sure there aren't other clever attacks.
http://webcast.berkeley.edu/course_details_new.php?seriesid=...
filter even [1..4]
I've found most of the time when you're trying to get incredibly short expressions that aren't obfuscated, haskell wins.