110
linuxxx
6y

Ever had a 'why in FUCKS name would you do that?!?' moment with another programmer?

In my first study year we learned about PHP and how to write a login system. Most people would either do a 'select count(something like id) from users where username = username and password = password' or select the values based on the username/email and check if the password matches.

This guy selected everything from the table and FOREACHED the records while comparing if the username/password matched with an if within that loop.

I couldn't get him to understand how fucked up that system would become once you'd have loads and loads of users 😅

Comments
  • 21
    Pretty much every day....
  • 50
    ...and then he became CTO at Yahoo... 😱
    😂
  • 5
    @roli09 I guess you lol'd a lot.. xD
  • 0
    Um yeah. The username is the row selection. The backend only checks the row the user asks for. Checking every goddamned password? Why?
  • 1
    Though for passwords/logins, I prefer to use a password as a string that will, if presented to a function, will return a true value. That way I don't have to store any passwords, not even encrypted.
  • 1
    Almost every day at work sadly...
  • 2
    @bahua sorry don't get your password part. Can you elaborate a bit more?

    Or are you trolling?
  • 2
    @CurseMeSlowly

    Ha, definitely not trolling. I'll write up an executive summary later, when I'm not feeding my son.
  • 1
    I have a standard: languages that don't enforce " I use ' because it saves me keystrokes @okee
  • 3
    I pray you were checking hashes and not passwords
  • 2
    @CurseMeSlowly

    I have a, well I guess you'd call it an algorithm, that takes a base64 string, and generates a longer string from it. I have a perl function that only returns true if the originating base64 string interacts with the longer string. This way, I store the longer string, but that longer string is useless without its key, which is the base64 form of the password the user chooses. Also, I don't have to store the password in any form at all.

    It's not recoverable, but I can live with that. That's what keepass is for.
  • 1
    @bahua ahh so it is not like you are not storing anything .. first I thought you were saying no password and got really confused :D thank for the explanation
  • 1
    @strNameKyle I myself was of course, he wasn't though
  • 2
    There was that guy in class who used GET for his login and a session ID that is equal to the account ID.
  • 1
    Oh, you could simply change the session ID too since it was not a session. It was a GET Parameter.
  • 1
    @PrivateGER that pains me..
  • 2
    Just sort the data by random first, that way you'll throw in some "optinisation" as in average the later registered users could be more active (as old tend to "die" and you don't have to loop over the entire set of entries.
    /ironieoff
  • 1
    @Linuxxx I remember the first CRUD system I made as a school project back in 4th semester. I hadn't taken any SQL courses at that moment and had no clue how to JOIN tables. I ended up nesting many loops and making a bunch of SELECT's to query data I could've retrieved with just one single query. I feel embarrassed every time I look back to that code.
  • 4
    That reminds me of a time, long ago, when I needed to build a node.js application which had log in/sign up functionality for a club.

    So I bullshitted. I stored the user’s names and passwords in plaintext in an array and I just iterated through the array when one of them wanted to log in.

    I had a random string at the start of the array as it would crash if a user tried to log in or sign up when it tried to iterate through the empty array to find the user.

    Instead of using a database, I recorded all the users data to a JSON file.

    It was the ultimate bullshit. And it worked.
  • 0
    I'd foreach through them, but use the USERNAME in the WHERE clause. Passwords in PHP dbs should NEVER be cleartext or hashed. Instead you want to get the PHP crypt value from the DB and have PHP check it against the input 😀
  • 0
    @matt961 there is a lot more to concern. Memory is just the one that might fatally crash it. Network overhead. Performance (when retrieving it gets looped over to create the large result set. Probably faster than with a where statement but still) databases are designed to do this kind of stuff it's hard to beat especially with proper configuration/setup and that is without taking into account the network overhead.
    Even security might play a role as you load a shitload of credentials that might leak (especially with a programmer this dense)
Add Comment