Stefan_H

If you initially parse everything after the comma as the aside, you then have only the fact that "two onlookers" is not something that George coul be to allow you to understand the sentence.

And with your clever repartee, no one will be able to contradict you.

Sarcasm aside, your comment is useless. I think that there is still significant ambiguity in the sentence as written as you parent comment does. It is only saved by the fact that after the "and" is "two onlookers", allowing the reader to make logical sense of the sentence, but it still holds ambiguity.

If I read this correctly, the main negative point was that the author was not paid as much as his colleagues, though he did get the position. The author suggests this is because of his height. To me (a young professional in the software development industry) that screams that the author did not know his own worth and therefore did not negotiate a high enough pay. I'm young for the positions I have held, and am roughly of average height, but you can be sure that I will get paid the same or more than my colleagues, because I understand how much I am worth and I am willing to say as much.

I don't think anybody is saying that you shouldn't strive to understand crypto. I think the overall message is don't build systems with crypto unless you understand it, or have someone in your employ who does. If you don't understand crypto, you will likely implement it incorrectly. It's as simple as that.

Does the author not know how to write quotations? The use of parentheses instead of square brackets to denote the alteration of the quotation is confusing and painful.

The something you are (which generally doesn't apply to web-based authentication) are biometrics. So something you are - the pattern of blood vessels in your retina - is something very different from something you "do". The fact that you have "muscle memory" that allows you to sign your name a certain way would again be "something you are". I can't pass that on to someone else - only I can do it.

There are also some very important facets to Information security that you are missing. You describe security as being "based on knowing, doing, or owning something that no one else can". But this is not quite right. You are speaking to only one aspect of security - confidentiality. There is also integrity and availability. Additionally, you are only speaking to the authentication aspect of confidentiality. Your "knowing, doing, or owning" could be more succinctly described as authorization based off of "something you know, something you have, or something you are" which are the 3 main ways that someone could be identified as you they claim to be. Your signature example would generally fall under something you are - but an argument could be made for it being something you know as well.

EDIT:

You also described Public key cryptography as having "2 different keys. One allows for encryption and the other for decryption. In this case, the decryption key is public so everyone can decrypt." This misses the mark a little bit. The public key could be used to encrypt as well, so that only the holder of the private key can read the information. Using the private key to encrypt is generally used in digital signatures so that the recipient can verify that the sender is who they claim to be. This scenario doesn't attempt to keep the data secret, because anyone with access to the public key can decrypt the data.

How would it be cheaper if the refueling stations are free?

did you mean "who DDOS'es Github"?

In that case, wouldn't the 200x200px square with the anomaly still be highlighted as unique from the rest of the sand, since none of the sand would match it?

You managed to, in more words than the original article, completely miss the point of the original article...

None of what you assume a "fuck 'em" mentality means is suggested in this article. It doesn't say that you should go out and walk across the country, it simply asks "what if?". It tells you to consider other options, to do much of what you suggest in the last paragraph of your response, except in your response you still have the assumption that to be successful in life, one must "care about your success in the company (and in your career)".

This article to me is a reminder that I don't need to do what everyone else is doing, or expects me to do, in order to be happy. I need to do what makes me happy, in order to be happy. Sometimes those values align, sometimes they don't. And in the instances that they don't, if someone else has a problem with that - Fuck 'em!

So they finally got rid of those pesky creative writing classes, huzzah!

I totally mean skewed right. The big part of the curve is on the left.

Even if you take 78 birthday candles to mean reach the age of 78, then there is still an issue with that statement. Likely to reach the age of 78 implies that the median age is 78, not the average. The median age is likely different than 78 (my guess is lower due to the distribution being skewed left - but that is just a guess)

Your logic is infallible... I mean fallacious!

You hit the nail on the head... "an appropriate forum with as many readers as SO/SE"

Stack overflow on the other hand is for people to:

[A]sk practical, answerable questions based on actual problems that you face. Chatty, open-ended questions diminish the usefulness of our site and push other questions off the front page.

I have a real problem with this:

"I guess my point is, that if you want to become a programmer, you have to be comfortable with having to learn new things constantly for the rest of your life."

I really feel like this is the outlook everyone should take on life, not just programmers. Maybe the causality ought to be switched; good programmers are people who have a "learn something new every day" outlook on life. Hell, it could even be said that good people in any field are those who take that viewpoint on life.

The comparison is spot on. You do not need to "become a developer" in order to understand what is within the realm of possibility for developers to do.

I'm glad I'm not the only one who has to do something when someone corrects a person, but is wrong themselves. One of my BIGGEST pet peeves!

Post-holocaust is perfectly correct. The event of nuclear war is often refereed to as a nuclear holocaust. Note the lack of capitalization on the 'h' making it not signify the proper name for the event, the Holocaust. http://en.wikipedia.org/wiki/Nuclear_holocaust

This font: TiemposHeadlineLight - was VERY difficult to read and made me want to run for the high hills.

While I love the pointing out of logical fallacies, this is not necessarily an ad-hominem attack on the argument. I think this post provides important context for the reading of the article. Since I did not know of the blogger's background, this comment allowed me to put it into context.

It wouldn't necessarily 'just happen'. From what I can glean, the idea is that if you are trying to play the game as well as possible, then the portion that you originally learned would be played better. You could certainly intentionally play the entire game poorly, thereby masking which portion is the password.

There is a chance that if your DB is compromised, your code is as well. Additionally, what if you want to change your work factor, how would you handle doing that? If you upgrade your server environment and then all of a sudden realize that your hashing algorithm only take .1 seconds, when it used to take .5 you might want to change it.

I would only say that you would want to immediately reset all user passwords if the passwords were leaked, not necessarily if the algorithm that you are using is bad for whatever reason. And the idea would be to give users a couple weeks (or days) to log in and then force the reset on all the remaining(maybe once you get to a certain percentage of your active user base).

I like the method that link provided, but there are some drawbacks, needing to update every user record with a new hash (offline process) - this is almost guaranteed to require taking the site down, which most people do not like to do. This is because you can't have some users with the old hashing process ,and some with the new.

When I say "Add in interoperability of hashing functions", that is pretty much exactly what I mean. I realize I left out the specific method for converting the hashes over. And your separate column for when the hash has been converted is the equivalent of my suggesting for a HashVersion column. Also, you will likely never be able to "quietly remove the old way" because not all of your users are guaranteed to log in again. But yes, the idea would be to verify against the old hash, save the new hash when the user logs in.

Salting is no replacement for strong passwords, this would work against most any salting scheme.

Sure - but the idea of salting is to make the dictionary too time consuming to create. The security is NOT in how secret your methods are (it rarely is).

Additionally, each salt is still unique per password, so the attacker would need to generate a full dictionary per record that they want to crack - generally not worth it.

Yes, storing the algorithm used in the same column would be fine as well. But if you drop the "bcrypt$" from your example, you would still run into issues if bcrypt itself is broken.

I do not see this as premature optimization. Do you store timezone information with your dates even if you are not operating in a different time zone? Do you store measurement information with a unit even if you love inches? I would say that it is certainly planning ahead, but it is not a premature optimization. It is planning for the all-to-likely event that you will need to start hashing your passwords in a different way.

"when it's easy to retrofit later" - I think this is the key part of your statement. When is it easy to retrofit later? You then have to pick your poison:

1. Switch entire system over to new hashing function - reset all user's passwords 2. Add in interoperability of hashing functions - what I'm suggesting you do from the beginning, making it much easier to do.

Number 1 is a horrible user experience, number 2 is much easier to do from the onset.