293 reputation
16
bio website
location Germany
age
visits member for 3 years, 6 months
seen 21 hours ago

May
10
awarded  Nice Answer
Jul
13
awarded  Commentator
Jul
13
comment Is code reviewing good practice?
Finally a reasonable answer. I found it far more effective to do revievs with just the developer and a single reviewer than doing it in a group. This way it's much easier to deal with mistakes for both sides and you can occassionally slide into pair-programming without wasting the time of the others in the group.
Jun
14
awarded  Yearling
May
29
comment C++ Interview question
thanks a lot @Steve Jessop and @Jonathan Leffler
May
29
comment C++ Interview question
Would someone please be so kind and explain a bit what is meant with trap representations in the context of accessing some address as int* as opposed to unsigned int* ?
May
18
comment Why almost no webpages hash passwords in the client before submitting (and hashing them again on the server), as to “protect” against password reuse?
Sure, SSL would solve this too but for proper SSL you need to pay recurring fees for the certificate and you need way more CPU power if it's a high load site. And it's actually not much effort to implement it, it took me maybe twice the time I already wasted here describing it.
May
18
answered Is it worth reading the language specification?
May
17
comment Is it worth reading the language specification?
You nailed it! That's how it works. ;)
May
17
awarded  Critic
May
17
revised Why almost no webpages hash passwords in the client before submitting (and hashing them again on the server), as to “protect” against password reuse?
added 4766 characters in body; added 105 characters in body
May
17
comment Why almost no webpages hash passwords in the client before submitting (and hashing them again on the server), as to “protect” against password reuse?
Jarrod, please follow your own advice and get a bit informed yourself before you make ridiculous claims. A man in the middle attack is useless against secure hash functions with reasonable salt length. And my suggestion is in no way 'security by obscurity', it is actually safe based on what is currently known and accepted by the experts in this field and it is used the same way in many protocols. It is not my invention, I just applied a well understood procedure to a website login. Your false assumptions don't gain any substance by the fact that they are obviously shared by many others too.
May
17
comment Why almost no webpages hash passwords in the client before submitting (and hashing them again on the server), as to “protect” against password reuse?
@Jarrod: It can actually be implemented in a secure way, see my answer for one possible approach. So you are obviously right, security problems and solutions are not easy to comprehend for quite a few people as can be seen on this question. I got 3 down votes for a working and secure suggestion and this answer is voted top although it is simply wrong. ;)
May
17
comment Why almost no webpages hash passwords in the client before submitting (and hashing them again on the server), as to “protect” against password reuse?
While client certificates are a reasonable approach for some use cases, they are not something that can be added easily to a website login. They require a great deal of cooperation from the users and depend on how secure the users private key is. The usage of a private key can be either secure or convenient but not both at the same time.
May
17
comment Why almost no webpages hash passwords in the client before submitting (and hashing them again on the server), as to “protect” against password reuse?
Yes, if you don't have javascript turned on you can't login. But this is no problem for sites that already depend heavily on javascript. Allowing plain text logins as well would of course be a option too. And you are wrong, you can't decode the password from the hash, even if you know the plain text salt. You would need to break the hash function, which is not yet possible. All you can do is running a dictionary attack against the hash which would be much more computing intensive than usualy, since you cant use rainbow tables to optimize breaking many passwords in a row because of the salt.
May
17
awarded  Supporter
May
17
revised Why almost no webpages hash passwords in the client before submitting (and hashing them again on the server), as to “protect” against password reuse?
added 711 characters in body
May
17
answered Why almost no webpages hash passwords in the client before submitting (and hashing them again on the server), as to “protect” against password reuse?
May
17
awarded  Editor
May
17
revised Is writing dead code useful?
added 391 characters in body