1. 25
  1.  

  2. 8

    I worked at a place where if you wanted to change your password, you sent a change request to the internal devs, who would patch the list of hardcoded username/password pairs embedded in the application.

    1. 3

      Were the passwords in plaintext?

      1. 5

        Yep.

    2. 2

      Nowhere as bad as others, but I once worked at a place with a hand-rolled secrets management system. It stored all values in SQL Server in an encrypted form, and the only interface to it was a custom developed C# application. I was in charge of automating a huge chunk of their release pipeline, and this was a huge pain point - the app was not something you could script; instead, you needed to get a release engineer to log in with their credentials and change whatever configuration flags you needed.

      So I cracked open the source. Your username and password went through a local PBKDF2 stretching function - cool, I’m expecting to see some sort of SRP-esque approach. Nope, dead code path.

      Once that “login” was done, the app pulls down a plaintext password from MSSQL and reads a compiled in username, concatenates them together, stretches another 10k rounds of PBKDF2, and uses the derived key for AES-CBC.

      I guess it best case meant an attacker needed the configuration manager binary as well as a DB dump, but it still felt like just embedding those 16 magic bytes in the build pipeline would have made for less effort.