• 5 Posts
  • 1.89K Comments
Joined 2 years ago
cake
Cake day: June 18th, 2023

help-circle





  • That’s true, there’s no way to know what sort of back asswards string modifications are happening to the password before it makes it to a hashing function, if it ever does. But the OP did say they told him his previous password was too long, and he was required to change it, so they were either storing it in plaintext, or storing the length of it somewhere. One is really really bad, one is weird, but also bad







  • I think it’s a nonzero chance they’re not hashing it. Pretty much every hashing function, in the interest of preventing collisions, provides vastly different responses on small amounts of input. Even if they were hashing it, it would just appear to be the same password in a situation where they somehow got a collision, but again, the column length for passwords would always be fixed since a hash function always outputs the same data length.


  • Not how password hashing works. Demonstrated with sha256:

    hunter2butitsreallylong:
    a9953dfbfec699349341edc857dcfe5c7a617c81f312cf57297d5b852881bab3

    hunter2:
    f52fbd32b2b3b86ff88ef6c490628285f482af15ddcb29541f94bcf526a3f6c7

    a hash algorithm encompasses all provided data and returns a single fixed length data response

    https://en.wikipedia.org/wiki/Cryptographic_hash_function

    Any changes, even just removing a few characters, drastically changes the output of the hash function (https://en.wikipedia.org/wiki/Avalanche_effect)

    You have no way of knowing a user password when you are storing hashes, you can’t truncate them, and the user password length doesn’t matter (up to a certain point where it’s technologically dumb to hash user input over a certain amount of data)

    I do agree however that changing / randomizing your password is important, as someone brute forcing or running rainbow tables etc on a hash dump can quickly attack a common password across different dumps


  • Absolutely, I’m definitely not criticizing the devices, I have an iPad Pro and the thing is very impressive in terms of computing capability for such a thin and light device and especially considering its battery life.

    My only gripe is with the restrictions on the OS. I’d love to be able to use Darwin on iPadOS the same way I do on Mac for local development tasks.

    With Apple opening up restrictions so we can use things like https://apps.apple.com/us/app/utm-se-retro-pc-emulator/id1564628856 for emulating other OS’s it’s certainly a step in the right direction, but I do wish they would consider the other “pro” side of potential mobile computing users, one side is creative professionals (photo/video/audio/writing), but they don’t have that same support for the development side of the pro world.

    Hell, I’d buy an 11 inch MacBook Pro or Air with an M series chip in a heartbeat, but it’d probably be easier if they just opened up the iPad to a local dev environment




  • Why? Probably some wild row length limit being hit where a table storing user data was storing an asinine amount of data, just terrible DB organization in an org where someone said “who even needs a DBA.”

    How? If you can truncate user passwords, you should never handle user passwords again, unless you’re a student or hobbyist learning a valuable lesson.