KeithS

2,594 reputation

316

bio	website
	location
	age
visits	member for	1 year, 2 months
	seen	May 13 at 14:37
stats	profile views	45

	2,594 reputation	bio	website		visits	member for	1 year, 2 months
316 badges		location			seen	May 13 at 14:37

summary answers questions tags badges favorites bounties reputation activity

111 Comments

suggestions reviews revisions comments badges posts accepts all

May 13	comment	How does hashing work? Well if you're using a secure hash (>=256-bit digest size) then storing the hashed value of "password" is going to increase your storage size. In addition, if an attacker were ever to see that 50% of the user accounts had the same password hash, he'd know that all he'd have to do is crack one password and he has access to 50% of the user accounts. You should be "salting" your password hashes; there are a variety of methods, but the end result is that the same password hashed by the same algorithm produces a different digest, because of an additional unique salt value for each account.
May 9	comment	How do spammers verify the validity of a huge amount of email addresses? ... and in that case they don't care.
May 1	comment	Is publishing your public IP address a security threat? This. Posting your public IP on a message board might raise interest in trying to hack the computer or network behind it, but there's really no way to avoid someone else knowing about it (even if that person is the anonymous proxy gateway you route your traffic through).
Apr 12	comment	How is “hacking” even possible if I “defend” properly? "As the defender, you must win 100% of the time. A hacker only needs to win once." - This, x1000.
Apr 5	comment	DDoS - Impossible to stop? Short and sweet, but somewhat incorrect. Most DDoSs are the result of a botnet. Botnets, however massive, are a subset of the Internet, that attack by making sustained, rapid requests, often in a manner differing significantly from legitimate traffic (no legitimate user sends SYN after SYN without completing the handshake). More sophisticated attacks that turn legitimate users against a site (DNS hacking, malicious Slashdot-style linking) are harder to defend against, but also harder to pull off and control (as in Tom Leek's analogy; you set it up and hope for the worst).
Apr 5	comment	DDoS - Impossible to stop? @makerofthings - Your ISP is still trying to send all other traffic to you, and you still have to perform some cursory inspection of the packet to determine it's a rotten egg. It's a losing game; a coordinated DDoS attacker can add zombies more easily than you can reduce the time/effort needed to reject their packets.
Mar 6	comment	Could once infected machine be ever trusted again? Regarding the last two sentences - While I totally get the point, I'm not sure that's fair; the whole point of modern computer/OS design is that you don't have to know the bits and bytes at the hardware layer in order to write quality end-user software. Saying that anyone who doesn't know how to store a virus on a keyboard's EEPROM shouldn't write software is like saying that anyone who can't pick a deadbolt shouldn't be replacing the exterior door of a house. Two completely different skillsets are required, and while one person may possess both, one does not require the other.
Feb 18	comment	Encrypt data within mobile app and send to web service When (not if) your application is reverse-engineered, you will have zero control over what string-generation function, or even what encryption function, will be used. You can trust your own servers. You can trust an end user after they prove they are who they say they are beyond a reasonable doubt. You can never trust the client software, or the machine it runs on.
Feb 18	comment	Strategies to store/remember very long password? True, but a OTP is not a "password". This question asked for advice regarding passwords, so it's a different question that I answered differently; I made the (safe) assumption of using 128-bit symmetric encryption, which would be safe enough for 100 years assuming the cipher primitive used does not demonstrate a weakness in that time.
Feb 18	comment	Strategies to store/remember very long password? The context of the question was future-proof security, linking to a question asking specifically about encryption strong enough to withstand 100 years of trying.
Feb 18	comment	How is distributed computing security ensured? Incentives is a rather big one; that's how Bitcoin works, by awarding new Bitcoins to the owners of the nodes whose transactions result in a hash value less than a given integer value. In that case, there's independent confirmation as well; other nodes can verify that the resulting transaction log does indeed hash to a particular value (with much less effort than the node which found it had to go through), and because the transaction system also works on peer confirmation, the other nodes can usually also verify that most or all of the transactions really happened.
Feb 18	comment	Strategies to store/remember very long password? A homebrew requires you to teach your children the complex nested hashing pattern on top of the nursery rhyme they should plug in.
Feb 18	comment	Strategies to store/remember very long password? Lastly, homebrew is unnecessarily risky. PBKDF2-SHA256 is a publicly-known, well-documented algorithm. It's undergone significant scrutiny by people much, much more knowledgeable about math and cryptography than you or I. As a result, you have the extreme advantage in using it of simply being able to tell your descendants to use it; "Remember that nursery rhyme I taught you when you were little? Run it through the PBKDF2-SHA256 algorithm iterated one hundred million times, and it will produce a key that decrypts a special message that will tell you where Grandpa's gold is buried."
Feb 18	comment	Strategies to store/remember very long password? Second, your repeated hashing doesn't add entropy, as I stated; however long the resulting key is, it's no more complex than the input. Repetitive hashing forms a proof of work; a process with no known shortcut which produces a result that's easy to check. They're designed to make computers work harder, not people.
Feb 18	comment	Strategies to store/remember very long password? Someone other than you has to know the KDF, unless you plan on living more than 100 years from now. First off, you don't actually need that long a key as long as each bit of the key has "full entropy" (it represents at least one bit of entropy of the input message). Given the 256 bits of a single SHA-256 hash, provided each bit has full entropy and there's no shortcut to guessing plaintexts vs keys, brute-forcing the key would require interstellar travel because we won't get enough energy from the Sun to power a thermally-perfect computer long enough to try all keys.
Feb 18	comment	Strategies to store/remember very long password? The main issue I have with this is that the repeated hashing doesn't add entropy, and it adds a relatively small proof of work. The resulting hash, however long and random-looking, will only be as complex, at its core, as the passphrase used to generate it. You're also advocating creating a homebrew KDF, which I simply can't condone.
Feb 18	comment	Strategies to store/remember very long password? Or "Rubber Hose Cryptography". Getting the password from a human who knows it doesn't have to be done with mind games, and it doesn't have to be pleasant.
Feb 15	comment	Why are vulnerabilities and lack of security possible in computers? Actually, that was supposed to flow into the quote from Dark Knight, but thanks for the uptick.
Feb 12	comment	Banning specific passwords? True. This could also be explicitly stated in advance as the rule "the password cannot consist of or contain any of the terms on the 'banned list'", providing some sort of link that would allow the user to view said list and the reasons words are on that list. I'm just worried that that might actually be going to far in itself, providing information to an attacker that can feed a cracking algorithm ("these strings will not be in the user's password"). But, would those entries really provide much of an advantage, when really all they're doing is removing the obvious ones he'd try first?
Feb 12	comment	Banning specific passwords? I guess I agree with the maintenance aspect and the use of more sophisticated cracking tools based on hints more tailored to the user. This measure was supposed to be a relatively simple guard against low-hanging fruit. Would a more descriptive error message about why the password was rejected help obviate the concerns with user frustration?