• Alistair (unregistered)

    It may be secure against a six year old, but I read about this type of encryption at junior school (age 10).

  • VAX_Assembly (unregistered)

    I worked for a company that used something similar to store customer passwords. Customers who could have used their password as their email password. If we have someone's email password and email address, we could have probably hacked any account that they cared about, financial or otherwise. Fortunately, they eventually saw the light and hashed the passwords with salt.

  • Ashamed (unregistered)

    I confess I am responsible for an even worse "encryption". Knowing it was bad to store or even transmit cleartext passwords, I designed the API so that on every call, you had to submit the MD5 of your password. Without salt. Over http. These MD5 were stored in the database.

    Thankfully this was many years ago and has been eliminated.

  • dpm (unregistered)

    <meme src="We're the Millers">You guys use passwords???</meme>

  • (nodebb)

    This is unnecessary complex, ROT-13 should be secure enough for anything!

  • (nodebb) in reply to Ashamed

    People often get the details right, but screw up the big picture.

    I just looked at a system that had dutifully upgraded DES to AES to keep up with modern security standards. Unfortunately, this was used in the password storage feature and we were storing password encrypted (with a static and non-strong key) instead of hashed. Even worse, it uses ECB (https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#Electronic_codebook_(ECB)), so you can look at the raw data and see the patterns repeat.

  • my name is missing (unregistered)

    If it was good enough for Caesar it's good enough for you; after all, are you better than Caesar?

  • Brian Boorman (google) in reply to my name is missing
    are you better than Caesar?

    My friends haven't had the urge to stab me to death, so... yeah. I am better than Caesar.

  • burner (unregistered)

    No, it takes a six year old to decrypt it. Anyone older would not think something that simple....

  • Hal (unregistered)

    I would go with "malicious compliance" as an explanation for this WTF; but honestly the approach taken makes me think the answer might really be ordinary ignorance.

    I mean whatever the backed is using it probably had something as easy to use as encodeBase64({value}) / decodeBase64({value}) so this scheme was probably harder to implement.

  • Angela Anuszewski (google) in reply to Hal

    Hanlon's Razor applies.

  • ZZartin (unregistered)

    Hey if it's good enough for the encoder ring I got in my box of cracker jacks it's good enough for anything.

  • (nodebb) in reply to nerd4sale

    This is unnecessary complex, ROT-13 should be secure enough for anything!

    Obligatory "But just to make sure, we use double ROT-13!"

  • Anon (unregistered)

    Remember me of a company who "encrypted" credit card numbers using RC4, but without a nonce.

    For those who don't know the RC4 cipher, this means XORing a encrypted text with a known plain text will give you a value that can be used to XOR all other encrypted credit card numbers to get back the clear text.

  • Bet Rob (unregistered)

    Close to 20 years ago, we were using forms-design software on our IBM midrange, with a GUI designer on the PCs. While looking one day through the folder the designer client was installed in, I found a plain-text file where the settings for transferring forms to and from the midrange were saved. These settings included the system name, library ID, user ID, and the user's "encrypted" password.

    This so-called encryption worked as follows: Take the first character of the password, and shift it up one. Shift the second character back one. Continue alternating through the password.

    My daughter was in her first month of first grade at the time, reading reasonably well. That evening, I showed her a common word and its encryption, and asked her if she could see a pattern. She picked it up right away, and was able to encode her first name without any help.

    When I reported the problem to the vendor (we'll call them BBPLTnmtuhpot), I made sure they knew that my six-year-old had been able to break their encryption.

    There were so many other egregious bugs and performance problems with this software, that we started looking for a replacement not long afterward.

  • (nodebb) in reply to Brian Boorman

    As far as you know. Maybe they just haven't acted on that urge.

  • Scott Simmons (unregistered) in reply to Ashamed

    @Ashamed--I think I took over maintenance responsibility for that application, or at least one designed with that exact 'security' system. I lived in fear for several months that corporate info security would see it and think it was my design, until I finally managed to get it shut down.

  • (nodebb)

    Are many tax id's text stings like "...LLUN..."?

  • (nodebb)

    Related...

    "Why do we need to pay 50c / day for our global auth service? Everyone I consulted told me we can just hash the passwords ourselves!"

    "We've been there, remember? It was about two days of work. Then you asked me something about the cloud..."

  • (nodebb)

    This is terrible encryption. In addition to just adding 125, he should've then subtracted 78.

  • (nodebb) in reply to burner

    A six-year-old could understand this encryption scheme! Someone go out and get me a six-year-old child!

  • Steve (unregistered) in reply to stoborrobots

    You forgot to reverse the string. It's NULL. That's actually in the data... We did some conversions from acquisitions into this system, and apparently the value NULL got interpreted as a string literal instead of an indicator that the field should be NULL. I found those when I was looking at something else and wondered who had 4 character tax IDs.

  • Some Owl (unregistered) in reply to Bet Rob

    I suspect there is a typo: BBPLTnmtuhpot => BBPLTnmtuhpmt? ;-P

  • (nodebb)

    If base64 is encryption, then so is ASCII. Job done.

  • David Mårtensson (unregistered)

    When I started working in the field I found that the accounting software we where using used almost the same encryption as the article.

    But instead of storing it as ascii numbers it just shifted chars around and reversed.

    I did not have access to the code, just the file on disk with the passwords but it took all of 5 minutes to decipher the encryption just from the file since I knew my password.

    That was almost 30 years ago, I hope they changed encryption but I do not know, we changed software a few years later.

  • Geri (unregistered) in reply to Brian Boorman

    I don't know you or your friends. It's perhaps: not yet. Caesar is remembered 2000 years later. Just in case: will you be, too?

Leave a comment on “Secure By Design”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article