• Marek (unregistered)


  • WTF? (unregistered)


  • TB (unregistered)

    More like encraption..

  • someone (unregistered)

    Excuse me, it's clearly "encreption".

  • I am a robot (unregistered)


  • Julia (unregistered)


  • RLB (unregistered)

    Wot no ROT13?

  • K. (unregistered)


  • K. (unregistered)

    What happens if the text gets too long? Well, lets see...


  • Lorens (unregistered)

    That's very orginal indeed. The spellig, of course, not the encreption.

  • Martijn (unregistered)

    I came here to say "encraption", but I'm clearly not the only one with that idea.

  • Dave (unregistered)

    The more blogs and WTF posts I read, the more conversations I have with IT professionals the more I have sympathy for Luddites and those that insist on paying with cash.

  • J. (unregistered)


  • my name is missing (unregistered)

    Craptography is a common problem in many organziations.

  • Brian Boorman (google)

    Well, to be fair, they didn't call it encryption.

    Looks more like TRANSEC cover, without the SEC.

  • (nodebb) in reply to RLB

    This is just about as secure as ROT13, but with more characters in the output.

  • (nodebb)

    Ah, security through obscurity. If you don't know the encryption method, then you can't decode the message. I wonder if the person who came up with this password scheme was just using it as a filler until (s)he could implement a reasonable secure one-way encryption, but did not get around to it before the software was released.

  • Tim (unregistered)

    Looking at the context of the code, it's not really trying to encrypt as such - just adding in a bit of obfuscation so that the plain-text password wouldn't appear in log files etc. with any type of form-based authentication you're relying on a secure underlying transport to stop the user's password being discovered.

  • Sole Purpose of Visit (unregistered) in reply to Nutster

    I'm not wholly convinced that calling encode64 from Javascript on the browser qualifies as "security by obscurity."

  • Omego2K (unregistered)

    Are the deleted comments just mentioning the company name?

  • Alex Austin (google)

    Maybe they were trying to encode passwords in a way to accept any character without having to worry about escaping rules?

  • Paul Neumann (unregistered)

    Not sure why any of that code would prevent using a long password.

  • Ulysses (unregistered)

    I know the law, officer! This is encrapment!

  • Richard (unregistered)

    Not sure I see the problem here, some sort of encoding on the front end (presumanly to deal with encoding of unusual characters) and then presumably hashed on the server. (Any hashing, of any kind, would have no value clientside anyway)

  • MrAHoleDBA (unregistered)

    Hai guyz, am i doing it right? [System.Text.Encoding]::UTF8.GetString([System.Convert]::ToBase64String("I'm just an asshole DBA but even for me this is the worst thing I've seen in 2018"))

  • First (unregistered) in reply to I am a robot

    Wish I could decrapt what you have said

  • J. (unregistered) in reply to Richard

    Then the problem is that the frontend code is really badly named. Pair this with the spelling mistake which indicates the quality of (the absence of) their code reviews.

  • Daniel (unregistered)

    My bank used to enforce a password policy that prevents duplicate characters, anywhere in the password (eg. your password couldn't have multiple 'a's). Not only does that actually reduce security, the policy was not enforced on the server-side, only with JavaScript.

  • anonymous234252 (unregistered) in reply to Daniel

    So your best bet is to use 26 character passwords?

  • anonymous2342 (unregistered) in reply to Dave

    I use cash for reasons of basic privacy (a human right, banks etc. don't need to know where I spend my money, stores don't need to know who I am as you get warranty based on receipts anyway, etc.) and the acts of withdrawing physical money and paying with it gives me a great sense of how much I'm spending (as opposed to occasionally remembering to check my account balance).

  • RLB (unregistered) in reply to Dave

    Dave: there are more reasons than mere Ludditism to prefer paying with cash, as well. Psychologically, most people tend to spend more when they can just swipe a credit card than if they have to hand over a physical object. Of course, banks don't like it when people point this out, so they make a huge bluster over convenience and cost to shops and the safety of cash transport and so on. Some of these are marginally true, as well, but they'll never admit that the real reason for this push towards a cashless society is that it makes us pay more interest.

  • (nodebb)

    Would calling it "Excreption" be subtler than "Encraption"?

  • jerepp (unregistered)

    Encreption: 1. to put something in a very thin pancake, 2. pretending very simple stock encoding is good enough to hide a password

  • Duke of New York (unregistered)

    Sam replaced the function with inceptPassword, which encodes it four levels deep until even the password doesn't know what it is

  • Anon (unregistered) in reply to Richard

    I agree with Richard. For example, .Net 4.x doesn't by default allow form posts that include strings like "<script>". Perhaps rather than disabling this, they are just encoding on the front-end. That doesn't rule-out properly salting and hashing on the back-end.

    RWTF may simply be poor function naming, and lack of comments.

  • Tachyon (unregistered)

    Clever indeed, as the password is also ROT-286 encrypted before hashing.

  • Joseph Osako (google)

    Has Harlot Packherder (or whatever euphemism we are using for That Company today is) done anything right in software since, I dunno, 1986 or so?

  • Tsirf (unregistered) in reply to J.

    Thats twice as secure.

  • Alex (unregistered)

    It may be that encode64 is not the js build-in function... but a user defined one that actually performs some encryption

Leave a comment on “Encreption”

Log In or post as a guest

Replying to comment #:

« Return to Article