Comment On Super Secret Encoding

It is always truly amazing how many connection strings can be discovered with the highly technical cracking tool called "notepad.exe"!

In this case the IL could never be reverse engineered. [/sarcasm]

Chad:
As I've pointed out before, you have no way of telling what charset it's encoded in. It could be UTF-32 for all you know, although it looks more like ROT to me.

Oh, I totally forgot to mention the user database in a very popular mortgage program. I was looking in the files - one for each folder, not centralized, a wtf in itself and a constant headache to manage - and it turns out they're encrypted in this way:

In each string field (name, user name, password) subtracting 7 from the ascii value of each character.

I guess they rely on the ultra-secure methodology of hoping no one opens the file in notepad.

Hey, this wasn't produced by this famous oracle guy, was it? --> http://dba-oracle.com/redneck.htm

:D

"dvt3ragm"

At least its not the combination I use for my briefcase.

Without defending the code, it would be unfair to say this sort of encryption carries no benefit at all. It does; the people who read and remember the above as easily as they would read the plaintext password are fairly few. This "protection" (I'd bold the quotes if I could) does in fact protect the password from being read over the coder's shoulder. That's not a real showstopper for anyone really wanting to crack the system, but it might avert some random attempts mostly fueled by curiosity.

The biggest risk with this sort of "encryption" is the fact that it can provide a false feeling of safety. But then again, would we consider a simple plaintext connection string a real WTF? Unlikely, as it's such a common phenomenon. If the decision to use ASCII values was a conscious one, it's not necessarily any worse than the everyday plaintext approach (perhaps except for a large production system, where the likeliness of somebody misunderstanding the level of protection provided is greatly elevated by the number of people using the source).

It's really not that bad, there's probaly no better solution out there. I guess you might just forget about the obscuring and put the password in in plaintext. The obscuring isn't purposeless; it does keep the casual code reader from seeing the password.

if any string in there is worth pseudo-encrypting it's 'password' because that's what the script kiddie with 10 seconds of access to your machine is going to grep/file-find for

@ Jouni
"This "protection" [...] does in fact protect the password from being read over the coder's shoulder."
This is true. It's like the tiny little lock you find on luggage. It helps keep the honest people honest. Because, if your underwear were just falling out all over the ground, who <i>wouldn't</i> <b>"</b>accidentally<b>"</b> look?

~JOSh-X

I'm kind of feel a sad of those black hats out there when this way of keeping secrets becomes popular.

Hey, it probably counts as encryption under DMCA.

I'd say convert _every_ character in the connection string while you're at it. Now where is that "real programmers code in binary" picture....

He should use ROT26 instead.

Hey Guayo, it looks like you're pretty good with this encrypting stuff. I had a hard time "deciphering" your last comment.

<i>I'm kind of feel a sad of those black hats out there...</i>

Nice. You can't even post simple HTML tags.

@Dr. Seymour: which DMCA? The RUN-DMC A? LOL

<i>italics</i>
<b>bold</b>
<blink>blink</blink>

@Supreme Coder
I know... :(
English is not my first language (or second for that matter).
Anyway, what I meant to say was: "I kind of feel sad for those..."

notes to self:
1) re-read at least 2 times before posting in english forums.
2) re-think about using a disclaimer like... Sorry about my English, I know it sux.

I wouldn't call this a WTF. It may not be great security, but it's better than the infamous practice of leaving the login & password in plain text.

Flawed security is better than no security at all. If an automated .Net dissasembling scanner pulled "login" and "password" from .EXEs at least something funny would show up in the results from this scan. Every extra step you put a hacker threw, the better.

Travis Owens: I haven't tested this, but I wouldn't be surprised to see the compiler "optimize" this into one string, with the constants added together at compile time instead of runtime. So basically, it would be easier for the bad guys to get at the connection string than it would for developers.

Yeah, it may be hard for non-programmer people to get the password out of (char)123, this password is embedded within the code. So if the password to the database changes, you have to recompile the code and deploy it again. So what's the point of hiding the password this way anyway? None of none-programmers will have access to the binary file anyway. This method is way too silly to me.

Travis, i think you're right... a decompiler/disassembler would usually return "808" on this (at least, the one i tried did).

try this on a C# page:
Response.Write((char)100 + (char)118 + (char)116 + (char)51 + (char)114 + (char)97 + (char)103 + (char)109);

vs.

Response.Write(((char)100).ToString() + ((char)118).ToString() + ((char)116).ToString() + ((char)51).ToString() + ((char)114).ToString() + ((char)97).ToString() + ((char)103).ToString() + ((char)109).ToString());

Alright, just for amusement here's the disassembly from C# via reflector:
Dim objArray1 As Object() = New Object() { "Provider=OraOLEDB.Oracle;Data Source=_censored_;User Id=accDbUser;Password=", "d", "v", "t", "3", "r", "a", "g", "m", ";" }
Dim text1 As String = String.Concat(objArray1)

and knowing is half the battle

One good thing though: because it seems C# still leaves the string concats in there, running something like strings only gives you the "Provider=OraOLEDB.Oracle;Data Source=_censored_;User Id=accDbUser;Password=" portion. The rest of the strings don't seem to be anywhere near the other portion.

I know too little about PE files and how the compiler would optimize string allocations and the such.

You are all in violation of the DMCA for Attempting, Suggesting, Inducing or just looking like you might try to break this encryption!

You will all be served with subpoenas within the hour. Resistance is futile, you will be litigated.

I can one up on this WTF. In one system we have the programmer's couldn't figure out how to keep the password out of the source, so they just used a blank password.

But I'll agree there is no good way to do this. Even if you manage to make the connection string completley unavailable, someone can still modify the SQL queries in your app. Or someone would eventually write an ODBC proxy to spit the passwords out before sending the connection string to the realy ODBC driver.

I can appreciate the benefit of this type of encryption. I worked in an environment where I was sharing a big open-plan room with a dozen customer service reps, a half-dozen salespeople, and another half-dozen admin staff. There were always people walking past me, looking over my shoulder to see what I was doing etc.

Yeah, that code is just crazy. Everybody knows that 8 char passwords are way too short.

"12345678"

Alberto: You'll never take me alive!!!!!!!!!11one

"That is, so long as they don't have the Little Orphan Annie Secret ASCII Decoder Ring ..."

BE SURE TO DRINK YOUR OVALTINE

"A crummy commercial? Son of a bitch"

When I first looked at I was thinking you had it all wrong as the Chr(..) replacements couldn't been non-printable characters.

But, holy shit, what a fucking idiot.

a) Don't hard-code your connection strings, put them in a configuration file.

b) If using SQL Server, use a trusted connection rather than username/password authentication, if possible.

c) Never use the sa/Administrator/whatever account to connect to your database from an application. It has far too many permissions and privileges. Instead, work out what permissions are needed for the application and assign those to accounts for the application.

I worked with a guy who did this same thing, along with spelling out the information in comments after each line being 'encrypted'.

Too bad it's not in unicode

@Supreme Coder
I know... I experienced that too: http://thedailywtf.com/archive/2004/11/15/3646.aspx#3655

What a moron. ROT-26 is not even half-way as secure as double-ROT-13.

Yes but where is a safe place to put this? I understand there is a secure store in Windows if the admin has this installed. But it wont always be there and I think its a tricky API to use.

we had a good one where I (am about to finish) work...

The server guys insisted we have a monitor page on the website that does a test connection to the database, but refused to change the code to update the password for the live server when they move it from staging. So we had to use a udl file that the web page can pick up to use for the connection string - and this they would change to supply the correct production password. As developers we're obviously not allowed to know the production server password for this system, but as we know the URL of the udl file, we could just type it into the browser address bar, and hey presto, IE happily downloads the file containing the live password. D'oh!

sCon = @"Provider=OraOLEDB.Oracle;" +
"Data Source=_censored_;" +
"User Id=accDbUser;" +
"Password=PleaseDontHackMe;";

I have a question for the group. I found that RUN-DMC A comment very funny. Is that weird?

Try this! This is much more secure! ;-)

sCon = @"Provider=OraOLEDB.Oracle;" +
"Data Source=_censored_;" +
"User Id=accDbUser;" +
"Password=" +
(char)(1100/11) + ((char)(18+25*4) + (char)(1+1+1+1+1+1+100+5+5) + (char)((int)(76.5/1.5)) + ... + ";";

Frankly this is awesome security compared to a helpdesk application our management team insisted we buy over all our objections (well it looked pretty: can you blame them?).

They used a SQL Server back end and - no joke - stored the sa password for the database in plain text in a publicly-accessible registry key.

To be fair, they did fix this six months after we raised it as a bug, but the real WTF is that they insisted that they had to use sa because nothing else had enough permissions.

Rrrriiggghhhttt.....

I think the real WTF here is that even Oracle has the possibility to use integrated security. (That means, no passwords required in connection strings...) (From Oracle 8i and up) (No, I am not an Oracle fan!)

Other thing is... why hardcode a connection string in a source file? Aren't configuration files invented for this purpose? Encrypted configuration files are easyer to use, and can be encrypted partially if nesecery.

So whatever this is... it's not good..... [:S]

Regards,


Jeroen

Alex Papadimoulis:

Adam's colleague revives a classic way of ensuring that no one is able to use your source code to figure out how to connect to the database. That is, so long as they don't have the Little Orphan Annie Secret ASCII Decoder Ring ...

sCon = @"Provider=OraOLEDB.Oracle;" +
        "Data Source=_censored_;" +
        "User Id=accDbUser;" +
        "Password=" +
           (char)100 + (char)118 + (char)116 + (char)51 +
           (char)114 + (char)97 +  (char)103 + (char)109 +
        ";";