- 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
At a place I worked at, they tried to store the CC number, type and expiration date, in the registry in clear text, with nice descriptive key names, so the user wouldn't have to enter the information in every time. I couldn't convince them to remove the information, but I was at least able to encrypt it and obfuscate the key names.
Admin
Heh. Sounds like the company I work for;
Admin
Admin
One reason why there might be no performance difference between CHAR and VARCHAR in mySQL is because in mySQL, if any column in the table is VARCHAR, all CHAR columns are silently converted to VARCHAR.
MySQL manual section 12.1.5.1:
If any column in a table has a variable length, the entire row becomes variable-length as a result. Therefore, if a table contains any variable-length columns (VARCHAR, TEXT, or BLOB), all CHAR columns longer than three characters are changed to VARCHAR columns. This does not affect how you use the columns in any way; in MySQL, VARCHAR is just a different way to store characters. MySQL performs this conversion because it saves space and makes table operations faster. See Chapter 13, Storage Engines.
So you're probably running a test that compares performance of a VARCHAR to performance of a VARCHAR, and discovering -- drum roll please -- they're the same!
Admin
And you'd be right.
And you'd be even more right that it's a completely gratuitous and unfounded one. I wonder what the complement of a troll would be. Is that ones complement, or twos complement? Does it take salt? Life would be so much easier if all internet trolls were slugs.
You are grievously misrepresenting the honourable Global Warmer. It takes far more effort to figure out the correct texting for something like "u r stoopid" than it does to cut'n'paste a /. comment along the lines of "Yeah, maybe you should find a new career." Why waste that much time on the likes of us?
Admin
I used to take it for granted that passwords should only be stored encrypted. Then I saw a post on a forum somewhere where the poster pointed out that if a hacker has gained access to your database so that he can read the passwords from your user table, why would he even bother? By knowing the passwords, he could gain access to your database. But if he's already there, why not just read the confidential information that he wants to read? i.e. if he's found a way to read the user table in your database, he can probably read any table in your database. So why get the passwords, then log in to the application and read the names and missions of your spies or whatever? Why not just read them directly from the database? If I was a thief and I broke into somebody's house, my next step wouldn't be to start searching for their spare keys. I'm already in. I'd be searching for the cash and jewels.
Not that I'm going to abandon encryption. Just an amusing thought.
Admin
Recovering the password is easy if you use a "Recoverable Obfuscation Technique" for your encryption. I prefer ROT-13.
Admin
Without the renowned power of the PHP operator ===, I am unable to discern whether TopCod3r is, in fact, TopCod3r. I think Alex needs to add some salt to the registration process.
If, as I suspect, TopCod3r === TopCod3r, then this has to be a stroke of genius. You can troll on completely opposite sides of the same argument: one registered, the other not.
Has TDWTF achieved an Internet First?
Or just an Ungentlemanly Third?
Admin
It has to do with preventing future attacks. You discover someone hacked your database, so you take the website down, fix the vulnerability, restore a backup of the database... then what? If passwords are clear text, you'd have to ask all of your users to pick new ones. If passwords are hashed, then it doesn't matter. Hashes are useless to the hacker, so you can just put your website back up.
Admin
Wait... actually I might be wrong. If he has write access to the database, then your users would need new passwords anyway because the hacker may have overwritten them.
Admin
If another DB user in my company has access to tables that I don't, like say, the payroll table, it wouldn't be useless to get that user's password.
Admin
The idea is that somebody may intercept the password in transit. Say, if your web application has a properly designed 5-tier architecture where each tier resides on a separate cluster, a corporate spy could be intercepting the passwords between tiers, giving your rivals open access to do whatever they want. Plus, it ensures that when you backdoor in access with a specific password hash, people can't see the secret all-access password.
captcha: inhibeo
Admin
Admin
Anyway, we both have better things to do. Uma Thurman? I'll toss you for her.
Admin
Admin
I am the real Top Cod3r, the un-registered one, but somebody registered that name yesterday to spite me I guess. So I decided to register this one, without the space.
I am just trying to add my opinion to the forum. I like the DailyWTF and if Alex wants me to stop posting my opinion comments, I will abide. I'm just trying to share my wealth of knowledge with some of the more junior developers who may be reading.
Admin
As I've already mentioned, that's no longer true. It's about time you stop reading the 4.1 manual:
Admin
Maybe we can get back to those halcyon days when you, I, FredSaw (blatant advert) and the tooth fairy used to read and respond to each other's posts, rather than the current round of trolling?
Me, I've got little hope of this. TDWTF has done exceptionally well, so far, partly because of the genius of the people who put it out. Unmoderated media do, unfortunately, degenerate to this point, which is essentially Omphalos.
Meanwhile.
If we can arrange it, let's have a bet on tossing Uma Thurman.
You can bet on how loud you make her scream, and I can make a counter-bet on how much the municipal waste man will charge me to take her away.
It'll probably depend upon how loudly she snores afterwards.
Admin
And you know how this is going to go. I'm going to be the schoolmarm.
Don't share your wealth of knowledge. Do comment in a way that conceals your wealth of knowledge, but still passes it on.
Me, I prefer being abusive and offensive and I don't really care about the pitiful morons that I offend ... and that's God's Honest Truth (as revealed in the Fifth Platinum Gospel, which I wrote yesterday in a mescaline haze) ...
You, I sense, have a more serious purpose in life.
Which is good. Follow your purpose.
Admin
So in Alaska we spell it CANCELLLLLLLLED_AK, since we're nearly 4x the size of TX. Some days we debate whether we should split AK in two just to make TX the third largest state in the Union.
Admin
Heh, I love how they salt it, but do it wrong.
The entire point of a salt is that all the passwords do NOT share the same salt. This is what makes them more resistant to dictionary attacks: the fact that you need to generate hashes with every possible salt for each password in your dictionary.
But what can you expect from a place that stores the plaintext right next to the hash?
Admin
Not true.
Smaller rowsize means more rows per page which speeds up retrieval of many consecutive rows.
Varying character fields may require a deferred update, which is slower than a direct update (this depends on the database engine, of course). Lots of other things can also lead to deferred updates (unique indexes, replication to name two) so I wouldn't get too obsessive over varchar/char choice.
B
Admin
don't get pissy with other people because you are unable to see the date row. The rest of us can and it is a varchar.
Admin
It really depends upon two things:
A highly skilled programmer who is firmly committed to eternal vigilance should be highly consistent. Any programmer who lacks one of these two characteristics will most likely not be as consistent.
FWIW, few programmers give a rat's butt about eternal vigilance.
Admin
OED says no.
Admin
By the way Chuck Norris is behind you and starting a roundhouse kick
Admin
Admin
I can top that. At a previous firm, I've seen at least 2 projects where the user data, including CC information for the 100s of users was stored in an unencrypted MDB (Access 2003, I think - not that password protection would have made that much of a difference)!
The 'security' (ha ha) was that the file was not downloadable.
Oh, btw, the website was open to SQL Injection.
:|
</lyle>P.S. I reported this to management, but I'm pretty sure nothing was done.
One of these days I'm gonna have to write about a couple of WTFs from that job.
Admin
In addition to the point KG and Monkey Brains made, if you know a user's password, there's a good chance they've used that password in other websites, like for their email.
Admin
Hence his mentioning that he "doesn't tend to take in the image in an article...".
He was responding to somebody else pointing out the varchar for dates in the image.
Admin
That's OK, but only if you use it twice on each piece of data to make it doubly secure. It also makes it easier to checksome.
Admin
Admin
I once inherited a project that had a "dafaut" field... was supposed to be "default" but had 2 spelling mistakes in a 7 letter word!
Admin
Ah, the dreaded dictionary attack!
Admin
The Real WTF is still using MySQL, even though vastly superior alternatives are available...
Admin
TRWTF is that this 5 paragraph text contains 5 open " characters and just two close " characters. Good thing that this is not code, cuz it wouldn't compile.
WTF is pecus?
Admin
Point taken. I'm just not in the habit of searching in non-indexed VARCHAR columns too often; typically, if it's something that's searched on any sort of a regular basis, either the column would be indexed or I'd be searching a subset of the data, and it wouldn't matter a lot.
Admin
...no, wait, more like... hallucination daze. Wandering bootheels; jingle jangle memories.
Admin
Well, that seems to be the end for this OP, then.
Bye folks!
Admin
ALL fields (except the INTEGER PRIMARY KEY id field every table holds).
Dates. Timestamps. References to the ID fields of other tables. Flags. Statuses. Dollar values.
Every. Last. Field.
so...
CREATE TABLE x ( id INTEGER PRIMARY KEY; ... ); CREATE TABLE x_to_y ( id INTEGER PRIMARY KEY; x_id VARCHAR; y_id VARCHAR; );
Spelling counts. Be sure to remember which tables use "SALE" and which use "SOLD", because all the code has to check against the string explicitly.
Admin
Yes, that's me.
Long story. I do some freelance consulting, I've been working with this guy for most of a decade, and when the consultant he hired to do something out of my fields botched, I was the guy who got called in to do emergency repairs. I would not have picked this project, and if I'd been more involved sooner, it would probably have gone very differently. :)
Admin
PICK-based databases store everything as varchar, in effect. However, there is a very comprehensive library of input and output converters built in, for dates and number formats and such.
Admin
What's the point? Well, first... consistency. Technically 'color' and 'colour' are both acceptable in English, but the day you see constants named "color_blue" and "colour_red" next to one another, someone needs a visit from the clue fairy.
Second, what's the point of two transaction states that are variations on canceled? What's the difference between them? Which one really means "canceled"?
Admin
I recently heard[1] that the hackers who stole personal information from TKMaxx were using sniffers to grab unencrypted data that was being transmitted over an unencrypted/weakly encrypted[2] wireless network.
[1] On the PRI Technology Podcast. [2] My memory isn't perfect and I can't get an upgrade.
Admin
That goes twice if you're working on a project for the British Government.
http://news.bbc.co.uk/1/hi/uk_politics/7570611.stm
Admin
It always strikes me how smart people can make such stupid mistakes. They figured out the MD5 thing and then bypassed its use completely. How come? Anybody?
Admin
It's not really true that all fields are varchar for simplicity: the userid seems to be int ^^
Admin
Storing password in clear text is not bad.
If you use a network, then you don't want the password to be send across the network, so you calculate a hash based on several fields including the password (e.g. webbrowser's DIGEST authentication).
The server must be able to do calculate the same hash in order to verify the password, so the password must be available in clear text.
Admin
The MD5 thing wasn't hard at all in any of the languages in use.
My guess is that it's just cargo cult; most of the rest of the code was. Full of huge chunks of code cut and pasted, adjacent cases which turn out to be identical but are written in wildly different ways, and so on.
Admin
You can do this with an already-hashed password as easily as with a cleartext password. You could then argue that the already-hashed value you store becomes the "real" password, but it's not what the user would type, at least; so, for instance, it gives some protection against getting all of a given person's other passwords too.