Learn More
Resend Email
41
badcopnodonuts
7y

What kind of cum gargling gerbil shelfer stores and transmits user passwords in plain text, as well as displays them in the clear, Everywhere!

This, alongside other numerous punishable by death, basic data and user handling flaws clearly indicate this fucking simpleton who is "more certified than you" clearly doesn't give a flying fuck about any kind of best practice that if the extra time was taken to implement, might not totally annihilate the company in lawsuits when several big companies gang up to shower rape us with lawsuits over data breaches.

Even better than that is the login fields don't even differentiate between uppercase or lowercase, I mean WHAT THE ACTUAL FUCK DO YOU SELF RIGHTEOUS IGNORANT CUNTS THINK IS GOING TO HAPPEN IN THIS SCENARIO?

undefined

your application will get pwned

its teeth knocked out and made their bitch

fuck you
Favorite
Ranter
Comments
  • 5
    7y
    AFAIK by far most passwords are transmitted in plaintext to the server, but over SSL...

    Or do you think people hash it on the client side before sending?
  • 5
    7y
    @qbasic16 I think this is how it is done. If you hash it from front end, theoretically user can get hold of your hashing secret. Rendering the hashing useless anyway. So plaintext password over SSL. Then hashing in backend to store. (And comparing with hash in dB to authenticate ) is what I think makes sense (well if not, fuck me. My whole life would be lie)
  • 2
    7y
    @rohitshetty mine too 😂
  • 2
    7y
    A person from the hostel management committee asked us(the college's student web ops team) for credentials for the mess complaint portal. It took ten minutes to explain it to him that his senior had changed it himself, and how we can't just see it since we've implemented Oauth.
  • 3
    7y
    @rohitshetty the hashing won't be useless in client if you take different salts for different clients. Bruteforcing a good hash with custom salt takes quite long. Intercepting the hash will indeed tell the interceptor that it's hashed but he has to re-bruteforce it for everyone due to having different salts. Combined with ssl, this will render mitm attacks second to useless as he still has to bruteforce that specific hash.

    Of course, hash again on server, there's no need for them to know and store that client hash.
  • 2
    7y
    @Tobyvw brilliant! Thanks for this info. Will incorporate this from next project!
  • 2
    7y
    @rohitshetty Glad to make the world a teeny tiny bit more secure👍🏻
  • 2
    7y
    Hmm on second thought. It will be more difficult to grasp the original password for the mitm attacker, however he could just send the captured hash to the server to gain access of course.

    However. It will save your users a bit from the attacker knowing their password for other services, given they most likely use similar passwords. That still requires bruteforcing it
  • 6
    7y
    hashPassword(userinput){
    //TODO add hashing
    return userinput;
    }
  • 0
    7y
    I love all these comments but our passwords aren't even encrypted. Not even encoded(I'd even settle for that as putting in some effort right)... they're literally in the db as plain strings. And sent like that.

    But I like this discussion you're all having! 👌🏼👍🏼
  • 1
    7y
    @alcatraz627 want to know your password, I'll just tell you because in our system our DB for your business has your thousands and thousands of customer passwords just sitting there.. visible. 👍🏼
  • 0
    7y
    @rohitshetty mine too haha. Would be nice to have ssl on the client side for those pages though. But nope.. that's not important lol
  • 0
    7y
    Change the column size and safe the hashed password when the users logs in next time and the password isn't already hashed.
Related Rants
devRant © 2021 Hexical Labs LLC
Privacy Policy  |  Terms of Service
Add Comment