1,020 karma · joined August 20, 2010
To figure out the actual distribution of people, you'll have to subtract 30 from the 16-20 range and then compare that with the 11-15 range, and then add back in the 30 votes distributed correctly.
While not strictly true (a better educated populous would probably earn more, and give more taxes to the state, among other reasons), I find the idea on this small scale amusing.
Am I the only one who finds this ironic?
Edit: Except, of course, for those who learn to predict 19 of 20 tickets correctly.
1) Never send untrusted data to the client.
How you do that isn't terribly important. It just matters that you do. Which is what that page is talking about: what you can do in order to never send untrusted data to the client.
Web developers would love it if there was a paragraph explanation that could explain how to prevent all XSS vulnerabilities in every site in detail, but there isn't.
HMAC(K,m) = H((K ⊕ opad) ∥ H((K ⊕ ipad) ∥ m)).
HMAC means Hash based Message Authentication Code.
Even using bcrypt set to take 1 second to verify a hash wouldn't be great -- it'd take about two hours and 45 minutes to break a PIN. And yes, while this is significantly better than not hashing at all (where it takes no time to get a pin) it would be trivial to target specific people to get their pin's given the hashed database.
Sure, you could make it take 10 seconds to verify a hash, but now all you've done is make me take a day to break the pin.
[1] Or rather, safer. There are always obscure ways to get around almost everything. So you really have to take care to exactly the situation you're in at the moment.
Edit:
Now that I think about it, why would you want to bookmark a link which modified state? The only time to use a nonce is to make it secure against CSRF attacks. You can't bookmark them when they're a post anyways, so you don't lose anything. Am I wrong somewhere?
However, this is a defense which works just as well for GET requests. Just put a nonce in the URL. /do.php?action=delete&id=3&nonce=88e3a6fe57854f2ed18c. Solves it just as well. (Another common solution is to duplicate the session cookie in the URL.) It is not bad form to have a get request which changes state so long as there is a nonce in the URL.
Edit: URL was being truncated.
I was 10 when I learned Java, and it always threw me off having to copy those first two magic lines which I never understood. What is 'public class'? Why 'static'? What even does the word 'void' mean? 'String[]'?!
Sure, after a few months I figured out the meaning of all of those words -- but it wasn't nice having to do that "open up last file I wrote / copy magic header to new file".
I don't think it's wrong to teach Java as a first language, but I think that there are better first languages which show what real computer science is faster than Java does. Less coercion of a language to do what you want and more free-flowing ideas.
String str = ""+5;
http://news.ycombinator.com/item?id=2035617
I'm not yet of the legal drinking age, so I'll pass on the beer.
Think about it like those little kid riddles: "A man is found dead with a noose around his neck and a puddle of water at his feet. How is it he was killed?" Put on a stool and the stool was removed? Then add the restriction "There are no stools." He was lifted with the rope? "The rope was tied to a bar on the ceiling and couldn't be raised higher." Raised in the air by some strong people and then let hang? "No one raised him from the air." You can make guesses all day long and I can make up excuses about why you're wrong until you finally guess what I wanted you to guess -- that he was standing on a block of ice.
More specific to your question: when I read it the first thing that came to mind was just to have an array of booleans and for each word in the table set H(word) to true and then when looking up a word check if H(word) is true. I don't know what bloom filters are, so I'm not saying this answer is better than them -- but after I suggest that instead of imposing some other restriction, ask me to think about what is wrong with my answer. Talk to me about the false-positives/false-negatives [or lack thereof]. Talk to me about what hash function I could use. Or about why I picked that way. Or what problems could happen if the hash function wasn't perfectly uniform.
A digital signature uses public key cryptography: one person can generate and sign messages, everyone else can verify. A common one is the DSA[3] -- but there are many others, including freakishly fast elliptical curve versions.
[1] http://en.wikipedia.org/wiki/Message_authentication_code
[2] http://en.wikipedia.org/wiki/Digital_signature
[3] http://en.wikipedia.org/wiki/Digital_Signature_Algorithm
If you'd like, I can email you all of the attacks I've found so you can fix them.
Edit: XSS isn't all there is to worry about.
I guess it makes sense that the media would call something like that invulnerable though, they don't know anything about it anyways.
I don't know how long it will take for people to figure this out. SHA-512 with a salt is not the right way to store passwords. Yes, it's better by leaps and bounds than storing the plaintext. Yes, it's better than crypt(3) as gawker used. But come on, just use bcrypt already.
And the fact that they calls SHA-512 with salts "invulnerable" ... I don't even know what to say to that.
Login Name: " onfocus="alert(1)" foo="
Submit form. Get error. Click input box again. XSS. Now, if I was an attacker, I would create a form which does this by myself and then post to that URL to get that javascript there when they visit the page, so as soon as they click the username it runs my JS.
Edit: This is on the create-an-account form.
http://en.wikipedia.org/wiki/Paillier_cryptosystem
But yeah, anything more than that is currently not all that practical.
Yeah, seven is just coincidental. But, it appears that you are correct in one respect: seven seems a bit high to me. I don't have the time to do the probability distributions out, if someone cares would they do the calculation and check?
EDIT: The salt 'sV' occurred 215 times. sV39Fw5at18zo occurs seven times. Assuming that there were only 300 possible passwords each of which occurred with probability ~.3% (the probability of '123456'), then the probability of seven passwords hashing to the same value is incredibly low. Less than a thousandth of one percent. Does anyone know why this is? Or was it just the case that Scorpion's assumption that the distribution is very non-random is correct?