Karl was enlightened only when Christian made sure that "testuser" wasn't the last entry in the database.

Um, wouldn't he have wanted to make sure it was the last record to provide the brick upside the head of illumination?

It wouldn't matter where the test record was, The method will still move though all the records in the table before completing. So it may be more effective to demontrate that the method continues to execute long after Authenticated is set to True.

Karl was enlightened only when Christian made sure that "testuser" wasn't the last entry in the database.

Um, wouldn't he have wanted to make sure it was the last record to provide the brick upside the head of illumination?

It wouldn't matter where the test record was, The method will still move though all the records in the table before completing. So it may be more effective to demontrate that the method continues to execute long after Authenticated is set to True.

BTW: Nice shiney new captcha

Actually it does matter, if a match is found before the end, the next loop through would set Authenticated back to false. The only user who could get in would be the last one in the database.

Just scanning over the code, it didn't immediately jump out that something was wrong.

It wasn't until the author mentioned that the test was seveal orders of magnitude slower with 10k users, that I realized what was up.

So I don't blame him for missing it as well... he probably coded the function quickly, without much sleep, on a deadline and trusted the test cases to be functional---i.e. test for all scenarios, not just one!

Would adding a WHERE clause suffice? I actually don't like the "SELECT * FROM" either.

What if, in it's next incarnation, the users table also includes user images (BLOB), copies of the user's id card (another BLOB) and a 500-page novel the user was writing while waiting for authentification.

The problem isn't so much the speed ...
It's that only the last person in the table can log in at all
- imma

It's worse than that. Assuming they are using SQL Server, when the server has many people logging in, then SQL Server will switch to merry-go-round scans of the users table, and each person may end up with a different "last" record. Nothing like a random output wrapped in a race condition. Yummy.

Why add a WHERE clause at all? There is no good reason to send the password back to the web server, hashed or not. A stored proc that checks the login and returns a true / false would eliminate the issue entirely.

Why's that? I persist hashes instead of the plaintext password all the time. But I'd be interested to know why that's not recommended (other than the inability to email passwords to the user if they forget theirs; I generally generate a new random password instead.)

Why's that? I persist hashes instead of the plaintext password all the time. But I'd be interested to know why that's not recommended (other than the inability to email passwords to the user if they forget theirs; I generally generate a new random password instead.)

Ditto to that. I never store the actual password, and I get quite upset with organizations that do. Especially when they have some random idiot in a call center asking me to repeat my password over the phone to them to verify who I am! WhyTF are they allowed to see it! WhoTF's bright idea was that!

But it's so rich! Here we go - misused SELECT, no WHERE clause, just plain wrong true/false setting.
The only positive thing is that it is not SQL injection prone. But I think that's just an accident.
Someone buy this guy a book.

Why add a WHERE clause at all? There is no good reason to send the password back to the web server, hashed or not. A stored proc that checks the login and returns a true / false would eliminate the issue entirely.

Do you think that makes the system more secure? You do realize that the hashed password already must go from the user's computer to the Web server, then from the Web server to the database right?

Why add a WHERE clause at all? There is no good reason to send the password back to the web server, hashed or not. A stored proc that checks the login and returns a true / false would eliminate the issue entirely.

Do you think that makes the system more secure? You do realize that the hashed password already must go from the user's computer to the Web server, then from the Web server to the database right?

Do you think it makes the system less secure? What if the user enters the wrong password? What if the username isn't even valid? Why send the correct password back to the web server when it can do the check at the database?

Why's that? I persist hashes instead of the plaintext password all the time. But I'd be interested to know why that's not recommended (other than the inability to email passwords to the user if they forget theirs; I generally generate a new random password instead.)

Ditto to that. I never store the actual password, and I get quite upset with organizations that do. Especially when they have some random idiot in a call center asking me to repeat my password over the phone to them to verify who I am! WhyTF are they allowed to see it! WhoTF's bright idea was that!

There are password authentication schemes that store the password in plaintext so that the secret must never travel unencrypted over the wire. CRAM-MD5 [RFC 2195] for example. Can come handy if no TLS is in place. It's all about tradeoffs.

Making this information available to a call center agent is wholly different WTF though.

Why add a WHERE clause at all? There is no good reason to send the password back to the web server, hashed or not. A stored proc that checks the login and returns a true / false would eliminate the issue entirely.

Do you think that makes the system more secure? You do realize that the hashed password already must go from the user's computer to the Web server, then from the Web server to the database right?

Do you think it makes the system less secure? What if the user enters the wrong password? What if the username isn't even valid? Why send the correct password back to the web server when it can do the check at the database?

I would as well go for a stored proc, it's definitely more secure because you don't have to send the correct password anywhere.

The way this code handles it, by sending all users and their password to the client is just about the worst security you can have...

While being entirely unable to login represents some inconvenience for the typical user, this implementation is preferred because of the superior security. A hacker can’t just guess anyone’s password. It has to be the password of the last user in the table. You can’t have security without some cost to usability.
--Rank

Why's that? I persist hashes instead of the plaintext password all the time. But I'd be interested to know why that's not recommended (other than the inability to email passwords to the user if they forget theirs; I generally generate a new random password instead.)

Ditto to that. I never store the actual password, and I get quite upset with organizations that do. Especially when they have some random idiot in a call center asking me to repeat my password over the phone to them to verify who I am! WhyTF are they allowed to see it! WhoTF's bright idea was that!

There are password authentication schemes that store the password in plaintext so that the secret must never travel unencrypted over the wire. CRAM-MD5 [RFC 2195] for example. Can come handy if no TLS is in place. It's all about tradeoffs.

Making this information available to a call center agent is wholly different WTF though.

fg

CAPTCHA: Tacos. Tasty, just had some.

Sorry, I should have been more specific. If they are just using something like "pass.GetHashCode()" for the hash, then that is not guaranteed to stay the same in future versions of the framework. Therefore, no user will be able to log in. If, however, they are using a fixed algorithm, like MD5, then that's fine.

Why add a WHERE clause at all? There is no good reason to send the password back to the web server, hashed or not. A stored proc that checks the login and returns a true / false would eliminate the issue entirely.

Do you think that makes the system more secure? You do realize that the hashed password already must go from the user's computer to the Web server, then from the Web server to the database right?

Do you think it makes the system less secure? What if the user enters the wrong password? What if the username isn't even valid? Why send the correct password back to the web server when it can do the check at the database?

I would as well go for a stored proc, it's definitely more secure because you don't have to send the correct password anywhere.

The way this code handles it, by sending all users and their password to the client is just about the worst security you can have...

Why add a WHERE clause at all? There is no good reason to send the password back to the web server, hashed or not. A stored proc that checks the login and returns a true / false would eliminate the issue entirely.

Do you think that makes the system more secure? You do realize that the hashed password already must go from the user's computer to the Web server, then from the Web server to the database right?

Do you think it makes the system less secure? What if the user enters the wrong password? What if the username isn't even valid? Why send the correct password back to the web server when it can do the check at the database?

I would as well go for a stored proc, it's definitely more secure because you don't have to send the correct password anywhere.

The way this code handles it, by sending all users and their password to the client is just about the worst security you can have...

captcha: waffles. Oh great, now I feel like eating some...

First, the web server and the client are not the same thing. Second, authenticating with a stored proc provides a security "advantage" only in the miniscule number of cases where someone is sniffing the network and also attempting failed logins with known usernames. Of course, they can still capture the hashed passwords of all the other users accessing the system at the same time as those passwords are sent to the Web and database servers.

Why add a WHERE clause at all? There is no good reason to send the password back to the web server, hashed or not. A stored proc that checks the login and returns a true / false would eliminate the issue entirely.

Do you think that makes the system more secure? You do realize that the hashed password already must go from the user's computer to the Web server, then from the Web server to the database right?

Do you think it makes the system less secure? What if the user enters the wrong password? What if the username isn't even valid? Why send the correct password back to the web server when it can do the check at the database?

I would as well go for a stored proc, it's definitely more secure because you don't have to send the correct password anywhere.

The way this code handles it, by sending all users and their password to the client is just about the worst security you can have...

While being entirely unable to login represents some inconvenience for the typical user, this implementation is preferred because of the superior security. A hacker can’t just guess anyone’s password. It has to be the password of the last user in the table. You can’t have security without some cost to usability.

Why would you want to tell your users that? It's generally accepted that telling the user that the username was okay while the password is not is a bad security practice, because then you've just confirmed to the attacker that now they only need to guess a password, and not a username/password combination.