- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
In a new project, this would be bad, but I have seen projects that are trying to do the correct thing by switching to a hash instead of plaintext passwords.
The problem is that most people forget to remove the column after fixing the code :P
btw, hashed password != encryped password
Admin
I can't even imagine what a perverse logic hides inside those megabytes :)
btw: OMG! I can't believe I'm first!! (maybe)
Admin
I don't see this as a WTF. It's so much easier for support to write a crack in case someone forgets their password. Had they made the table 600 columns, I might agree.
Admin
Your pride made you second.
Whats the "ullamcorper"
Admin
Admin
"all fields are varchar for simplicity...'"
If anything that's going to make things more complicated, because now you have type conversions to take care of. Have a datetime value stored as a string and you have to be mindfull of whether it's in EU (31/12/2008) or US (12/31/2008) or some ISO format (2008/12/31). If you end up with a mixture of different formats in your database due to sloppy coding (likely in this case) then you're royally F**KED!
And then you have INTs stored as strings where you have to perform careful/safe conversions into INT datatypes incase a bunch of characters ends up in the database.
Admin
"The salt is the name of the company the project is for"
Negating the fact that the password is stored in plaintext, aren't you supposed to use a salt on a per record basis?
Also, regarding the VARCHAR issue, I tend to use VARCHAR over CHAR for user inputed data, since (in MySQL) a CHAR field is padded with spaces, so when you retrieve it it strips the trailing spaces. A minor problem if trailing spaces should be retained (unlikely, I know). Also, it appears (again for MySQL) that there is no performance hit when using VARCHAR in INNODB tables, couldn't comment on any engines though. I do however use CHAR for storing HASHES etc.
Basically, I'm wondering if using VARCHAR should warrant such a sick feeling in the stomach.
Admin
@Dominic Pettifer
Hmm, I read "all fields are varchar for simplicity..." as using VARCHAR for text fields only, not for other data types
If that's the case, it does induce a sick feeling.
Admin
Wait, is that md5(salt + name + pass) or md5(salt) + name + pass? The first one isn't that insecure. For the second one, is the + operator addition or concatenation? Overflow's a bitch.
Admin
Uh, Sherlock, the point is that he used VARCHAR for EVERYTHING. That includes numbers, booleans, dates (as you can see in the screenshot), etc.
Admin
The comment is a VARCHAR for simplicity.
Admin
Fortunately for the developer, my opinion of him is encrypted to avoid hurting his feelings: !*7#
Fortunately for the rest of us, my opinion is also posted in unencrypted format: WTF?
Admin
I don't tend to take in the image in an article, but from looking at it, I can only see him using VARCHAR for text & a date. userid is an INT. An INT is a number isn't it Watson?
Admin
That's not that bad. My old company stored the password unencrypted too. They also stored the CC number and all other relevant and related info. First, you aren't supposed to store that at all and then they wouldn't encrypt it. That whole company is a giant WTF.
off-topic: Why not use re-captcha on the site?
Admin
"Now, I'd have thought this might be intentional, except that two of the states a transaction can be in are CANCELED and CANCELLED_TX"
So what is your point? You can spell the past tense of cancel with either one "L" or two. In Texas, they typically spell it with two because everything is bigger in TX which is the RW the F!
Admin
Perhaps this whole codebase should be submitted and considered for a MAJOR WTF AWARD. Alex, are you listening? A Tony/Emmy/Clio award for WTF!
Admin
The whole point of salting is that a guy can't precompute a massive list of all the common passwords. Same salt for all users is more secure than nothing, as the dude can't attack you with the same list he used to attack somebody else. But a per user salt would be infinitely more secure.
That said, he seems to be doing md5(salt + name + pass), so effective_salt == (salt + name). Hence, unique salt per user. The username alone wouldn't be terribly helpful, as the guy could find out if jsmith:swordfish had an account on multiple sites. but jsmith:[email protected] will hash to something completely different from jsmith:[email protected]
Admin
Admin
Alex put that image there. It's not part of the story.
Admin
"all fields are varchar for simplicity...'"
gawd, the lead developer at the place I used to work at did that. Everything was a varchar in the database, even dates. It also extended to his VB6 spaghetti which stored everything, even dates within his timesheet application, as strings (in slightly different formats everywhere so there were tons of different functions just to calculate differences between 2 times, etc).
Admin
Admin
That's beside the point. It was spelled 2 ways within the one code base. How do you know which spelling you should be using when you go to refer to it next?
Admin
Chuck Norris is a Texas Ranger.
Admin
It's true.
When I went to Dallas for a business meeting, my weasel grew by about two inches.
Admin
! In my hallucination you put random chars in the beginning of every line.
Admin
Wouldn't a WTF award be a Paula?
Admin
Axcoim? I mean Acxiom?
Admin
Ummm, actually Chuck Norris is someone who PRETENDS to be a Texas Ranger.
Admin
Yeah, maybe you should find a new career
Admin
It's not a comment, it's a stored procedure. @Dominic is a parameter of type Pettifer. The question mark is just a unary if operator.
Admin
Admin
"The salt is the name of the company the project is for"
Is that the name of the company in the screenshot of the schema?
Looks like a well known vendor of SQLServer tools to me spelled wrong.
Admin
Chuck Norris counted to infinity... twice.
Chuck Norris doesn't sleep. He waits. When Chuck Norris does a pushup, he isn't lifting himself up; he's pushing the earth down.
And... Chuck Norris IS a Texas Ranger.
Admin
And Texas Rangers pretend to be Chuck Norris.
Admin
OMG, did we work at the same place? Did he also not use Option Explicit so that variable mispellings would be quietly ignored? Did his timesheet schema have a table with Sun Mon Tue Wed Thu Fri & Sat as field names so that if you needed to calculate monthly, you needed fourteen variations of the same query? Did he have his own toaster oven next to him and stink up the office every afternoon with the smell of bacon or fries?
Admin
Admin
Hmmm ... maybe it's 463 different, poorly-indexed tables.
Admin
Strictly speaking, calculating an MD5 hash isn't 'encryption' since the hash isn't meant to be decrypted.
(one-way encryption, maybe?)
</nitpick>Admin
No WTF here, as long as your database is encrypted properly. Just go to Tools - Security - Encrypt/Decode Database, and then select your MDB file and then it is secure. I don't know why more people don't take the time to do this simple measure.
Besides if you encrypt the password itself, it becomes harder to make a password retrieval web page.
Those are just my thoughts, from experiencing securing my company's infrastructure.
Admin
I've been catching up with TDWTF this afternoon, and you sir are a comedy genius. :)
Thank you. :)
Admin
When a CHAR field is retrieved in any RDBMS, trailing spaces are not stripped, they are added. If you enter a single character into a CHAR(5) column, you end up with the single character plus 4 spaces. If you don't want the spaces, you have to trim them yourself.
The difference with a VARCHAR has nothing to do with stripping (or losing, for that matter) trailing spaces. A CHAR always takes it's defined amount of storage, while a VARCHAR takes up only what's needed. If you want trailing spaces in a VARCHAR column, you can have them - just add them to the value before you store it.
There's no difference in performance in any DB. The difference is in the amount of storage required. A CHAR(100) always uses the space required for 100 * SizeOf(Char) regardless of content, while a VARCHAR(100) doesn't; the VARCHAR will take the size of the actual data + a slight amount of overhead.
Yes. What the OP and comments to it were referring to is the improper use of VARCHAR. For example, defining a column that you know will store date values as VARCHAR. It makes comparisons and other operations more difficult, since you always have to convert from VARCHAR to DATETIME. You also have to worry about different formats; using the proper datatype allows the DB to make sure only valid data is stored.
I'd suggest that, before you post any more of your DB wisdom in public, you take a basic course in databases. Any "Teach Me SQL" or "SQL for Dummies" book will improve your knowledge greatly.
Admin
The point is consistency.
Admin
Almost, but not entirely true. When a table contains no variable length fields, searching on a non-indexed field will be slightly faster, since the DBMS always knows exactly where in a record a given field will be - it doesn't have to spend time looking at each individual record to determine the variable field sizes.
Of course, given that strict requirement for the added performance, it's not a very frequent scenario - and as a matter of fact, MySQL versions prior to 5.0.3 would silently convert CHAR columns (of 4 or more characters) to VARCHAR once you had any variable-length columns.
Admin
I'm also working on a project with "password_plain" and "password_encrypted" columns in the database! Is this a recurring WTF?
Admin
Holy shit, is this "seebs" from http://www.seebs.net ?
If so, dude, you were one of my inspirations as a programmer. What are you doing working on WTF projects?
Admin
Yes, that's what you do when you mess up the first time but don't want to lose anything.
Attempt 1: Canceled Attempt 2: Cancelled Attempt 3: Cancellled . . .
Admin
Seriously, what kind of comment is that anyhow? I mean, I'm not in the security business, so finding a new career would be irrelevant (unless I accidentally mistook a complement for an insult). But put some substance in your posts instead of just saying "u r stoopid".
So, how would you properly salt something and how would you go about attacking the first option from this one in such a way that a properly salted password wouldn't be vulnerable?
Admin
The point is consistency. Programmers should be the most consistent people when it comes to syntax, spelling and which caps they use.
If you had a constant named CANCELLED, you could not then call that constant by using CANCELED.
So why you would have enum values of CANCELED AND CANCELLED, both spelled differently, albeit correctly. You would always be forgetting which one was which.
It doesn't take a genius to figure that out.
It's the same as if you always start your class names with caps (and you should), then making a class name start with a lowercase is not very good practice.
The worst thing is when somebody mispells a variable (in it's declaration). And as opposed to fixing the typo, they propogate the entire file with the mispelling.
Admin
"The point is consistency. Programmers should be the most consistent people when it comes to syntax, spelling and which caps they use...blah, blah, blah..."
Thank you Captain Obvious for explaining in tiresome detail what every good programmer already knows. The point really is that it's a JOKE. Sure it is a little more subtle than "Knock, knock...who's there?", but it is a joke nonetheless. Pretty much everyone else got it.
Admin