Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

[P]
Ho, Ho, D'oh! Blogger Cracked for Christmas

By rusty in News
Wed Dec 26, 2001 at 07:51:14 PM EST
Tags: Security (all tags)
Security

As reported on MetaFilter, Blogger has been cracked. Blogger is a weblog service that takes weblog entries from a user, stuffs them into a template in front of previous entries, and uploads the result to the user's webserver via ftp. This has made it easy for people to keep a weblog without having to be a web designer, programmer, and sysadmin, and Blogger's free service has become one of the most popular in the booming weblog-management field. It appears that Blogger stores users ftp passwords in plaintext, so the safe assumption is that all Blogger users ftp passwords need to be changed immediately.

Read on for some guesses about the severity of this event, and possible consequences for the net.


ADVERTISEMENT
Sponsor: rusty
This space intentionally left blank
...because it's waiting for your ad. So why are you still reading this? Come on, get going. Read the story, and then get an ad. Alright stop it. I'm not going to say anything else. Now you're just being silly. STOP LOOKING AT ME! I'm done!
comments (24)
active | buy ad
ADVERTISEMENT
To plagiarize myself from the MeFi thread, the consequences of this could be pretty bad. Blogger reportedly has hundreds of thousands of users -- assume for the sake of argument that there are 150,000. Further assume that 10% of those users are inactive and don't pay attention to Blogger news, but still have valid accounts on their ftp server. So there might be 15,000 passwords that won't be changed. Say a further 10% of those are on machines with root vulnerabilities that can be easily exploited. That leaves about 1500 boxes that now belong to Mr. Anonymous Cracker.

1500 T1-connected machines are capable of collectively pumping roughly 1.5Gb/sec of continuous traffic, if they were converted to act as distributed denial-of-service zombies. That would be very bad indeed.

My suggestions for improving the future security of Blogger are here. Do any of you have better ideas Ev should consider? And are my estimates above even remotely grounded in reality?

Sponsors

Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure

Login

Related Links
o MetaFilter
o Blogger
o MeFi thread
o here
o Ev
o Also by rusty


Display: Sort:
Ho, Ho, D'oh! Blogger Cracked for Christmas | 43 comments (40 topical, 3 editorial, 0 hidden)
Got Root? (3.75 / 4) (#3)
by enterfornone on Wed Dec 26, 2001 at 03:21:07 PM EST

I think it's more likely that some cracker now has 150,000 Geocities passwords. Does anyone use Blogger with a real webhost? If they do, I would suggest the best security improvement would be to not give their ftp passwords to web sites that they have no control over.

--
efn 26/m/syd
Will sponsor new accounts for porn.
That's why I kept cutting it down (4.00 / 1) (#5)
by rusty on Wed Dec 26, 2001 at 03:31:20 PM EST

I assume that most blogger users have their blogs running on services like Geocities, which are probably maintained by security-conscious admins. That's why I cut the estimate by 90% at each step. First they have to get the passwords, then the passwords have to not be changed, then the machine has to be crackable.

Given all that, I think it's possible that 1500 such machines could be out there. I would hope not, but I don't think it's totally unreasonable. I'd be interested in some general stats about what hosts blogger users actually do use.

____
Not the real rusty
[ Parent ]

Hosts vs. Users (3.50 / 2) (#32)
by xrayspx on Thu Dec 27, 2001 at 09:20:48 AM EST

At one point in the writeup, it is mentioned that we assume Blogger has 150000 users. I doubt that those 150000 users would be on 150000 unique FTP hosts. More likely, you'd have them spread out over perhaps 20,000 sites, assuming many use webspace that, for instance, their broadband provider gives them (people.ne.mediaone.net/~someuser), or Geocities or somesuch free web service.

If you use that number of 25, or even 50,000 unique hosts to start your calculations again, then the end result is quite different.




"I see one maggot, it all gets thrown away" -- My Wife
[ Parent ]
Hopefully (3.00 / 1) (#33)
by rusty on Thu Dec 27, 2001 at 01:11:47 PM EST

Hopefully you're right. The reality must be somewhere between "Cracker didn't know enough to steal any FTP passwords" and my estimate, which was probably a worst-case.

____
Not the real rusty
[ Parent ]
1500 not that many really.. (4.00 / 1) (#34)
by ewan on Thu Dec 27, 2001 at 05:14:58 PM EST

When you consider the number of vulnerable windows xp machines out there (Upnp bug), or the number of vulnerable AIX and Solaris systems (login bug), realistically this is a fairly trivial level of hack.

If perhaps the whole 150,000 users had machines hacked, then you would be into interesting numbers.

Also, if you recall a couple of years ago an online cd retailer (cduniverse, i dont remember?), had it's credit card database stolen and something like 100,000 peoples entire credit card details stolen.

Around 1500 machines of I imagine fairly low importance being hacked is not that big a deal.

Which is kind of scary, isn't it?

Ewan




[ Parent ]
Well, here's one (3.00 / 2) (#9)
by theantix on Wed Dec 26, 2001 at 06:00:26 PM EST

Apologies for the double-post. This is obviously the real post.

Well, I used blogger for my travel journal when me and my girlfriend visited Europe and North Africa in the summer. And yes, I was dumb enough to save the password on the blogger site. Why? It was a really handing system for posting updates on the go.

Why save passwords on the site? They had some damn bug in their system that made the password prompt come up three times when updating the blog, and it was confusing my girlfriend. Since I wanted her to post too, I saved my FTP password onto blogger. Come on, was I really to expect that they would store their passwords in plaintext? WTF is going on with sites like that. Thankfully I was smart enough to use a unique password, and that I read this story and changed my password in time before anything was obviously cracked.

I'll look over my server logs to look for suspicious activiy. If anyone has any suggestions of what to look for in my server logs or anywhere else on my webserver, it would be appreciated (I'm using apache and FreeBSD).

--
You sir, are worse than Hitler!
[ Parent ]

Logs (4.33 / 3) (#10)
by rusty on Wed Dec 26, 2001 at 06:17:00 PM EST

First, change your password! You already did, so good. Check your FTP logs for logins you don't recall doing, or any that just look odd. Check the syslog for failed logins using your old password -- that could be useful in tracking down the cracker. They probably would be smart enough to use another cracked machine, or what have you though.

Of course, if someone did get in, and rooted you, the first thing they'd do is erase any suspicious log entries. So if you are worried, get some standard utilities like top, ps, ls, and so on from a trusted source (i.e. NOT your machne! Checksummed binaries from a distributor would be best) on a floppy or CDROM, mount it, and using those utilities, check your server processes and poke around the filesystem a bit to see if there's anything new or strange. The reason for using known-clean utilities is that if you were cracked, the second thing they'd do (after they wiped the logs clean) is install a rootkit with trojaned versions of all your standard utilities, that will be specially designed to not report all their DDoS tools or whatever.

Also, grab a copy of nmap and give your box a scan from the otuside for strange open ports. I personally do the full enchilada: TCP and UDP scans of all ports. Better safe than sorry. If your machine is just a webserver, you should have everything shut off except ssh and http (and I guess ftp, if that's what you were using for blogger. Might want to think about that in the future though). If you don't have everything else turned off, for God's sake do it now. If any ports are open that you didn't know about, that's probably a bad sign.

____
Not the real rusty
[ Parent ]

Password hashing suggestions (4.62 / 8) (#6)
by sigwinch on Wed Dec 26, 2001 at 04:37:28 PM EST

Ditch crypt(). It's easy to use a really solid algorithm with no surprises or platform-dependencies.

Using a salt is mandatory! Without it you have essentially no security. To prevent dictionary attacks, the salt *must* be large and random. Perfect randomness is not needed -- it just needs to have enough completely random bits that two passwords are unlikely to get the same hash, and that it is infeasible to build a dictionary for all possible salts.

The hash algorithm must be cryptographically strong. MD5 is good enough for casual use, and SHA is almost certainly good enough.

You can also use any block cipher in CBC mode as the hash. Make the salt the first plaintext block, the password the next block (padded out to the full block size with untypeable characters), and the final cipher output is the hash. Twofish and Rijndael would be good.

Salt + hash prevents a single-dictionary attack, where an attacker prehashes an entire dictionary and saves the results. This forces the attacker to run through the whole dictionary for each password, which greatly increases the computational requirements. Unfortunately if the attacker gets ahold of the salts, they can do a per-password dictionary attack.

Make the per-password attack harder by doing more calculations. Instead of just hashing salt + password, use salt + large_value + password. large_value should be large enough that hashing on an top-of-the-line CPU takes a long time, say 100 milliseconds. 100 ms would take 33 minutes to try a 20,000 word dictionary. large_value should be either constant, or derived from salt using a pseudo-random number generator. Of course, it'll take *you* a lot of CPU cycles to authenticate users, and you'll have to have enough spare CPU cycles available for the job.

Using large_value isn't perfect, but it at least makes the cracker earn the password, especially if you can afford ultra-fast CPUs/custom hardware and the attacker cannot.

You should also consider doing authentication on a *really* secure machine. Choose an extremely solid OS, install as little software as possible, and lock it down as tight as possible. Your backup strategy should involve either a visit to the machine, or extremely careful use of cryptography. My personal preference would be a box running DOS or QNX or something similar, talking to the web server over a serial cable using a checksum-protected protocol, with no NIC, and with physical locks on the case and removeable-media drive. Oh, and with a large, constant delay for each authentication attempt, regardless of whether the attempt succeeds or fails. Be sure not to authenticate willy-nilly to avoid overloading the authentication box.

--
I don't want the world, I just want your half.

About salts and large_values (4.00 / 2) (#7)
by rusty on Wed Dec 26, 2001 at 05:06:40 PM EST

If this is obvious, pardon my ignorance, but here's the question I have:

I understand using a random salt, which I should have done in the first place. As I mentioned in the MeFi comment, Scoop does it poorly because I didn't know what I was doing. What I can't figure out is how to keep the salt safe. That is, crypt prepends it onto the hash, so that hashing a plaintext password with the ciphertext will produce the original ciphertext. If I want to hide the salt, or make it tough to find, what do I do?

Same question for adding some string of bits on a password to make dictionary attacks harder. How do I make sure that in my authentication comparison, I can use the same string? Do I just define the salt and the random string somewhere secure on my machine, and take what security they get me if they don't get compromised?

____
Not the real rusty
[ Parent ]

Salts (4.66 / 3) (#11)
by sigwinch on Wed Dec 26, 2001 at 06:44:47 PM EST

What I can't figure out is how to keep the salt safe.
Do the best you can afford given your goals and resources. At the very least, the file with the salts must be readable by as few programs as possible. Ideally, it would only be readable by a separate authentication program that communicates with the web app over a secure connection (local socket, SSH tunnel, SSL connection, whatever). Under Unix, it would be a good idea to chroot(1) the web server and web app to help keep it away from the file with the salts and hashes.

If you want to get really fancy, you can keep the salts/hashes on a secure platform. Say, one of those IBM crypto cards, or even just a separate machine running a highly-secure OS. That's probably overkill for Blogger and Scoop though.

The real value of salts is in protecting strong passwords. Strong salt + strong password + strong hash algorithm == attacker must try all possible passwords (brute force attack). Use enough bits, and the sun will grow cold before the attacker can extract the password.

You control the salt and the hash algorithm, and you can make them strong. The problem comes from user-selected passwords. If an attacker gets the salts and hashes, all weak passwords will fall to a dictionary attack. To make passwords stronger, check for obvious weaknesses and don't allow the user to set poor passwords. There are libraries for doing this. (Linux PAM has a checker algorithm, and I'll bet CPAN has weak password checkers too.) Alternatively, don't let the user choose their own password, but give them a strong password from a good random number source. Downsides are that users will hate you, and you have to send the plaintext back to them and it might get cached by their web browser. Given the caching problem, I'd say a weak password checker is a reasonable compromise for casual systems like Blogger and Scoop.

Is that clearer?

--
I don't want the world, I just want your half.
[ Parent ]

Yes (4.00 / 1) (#14)
by rusty on Wed Dec 26, 2001 at 07:57:06 PM EST

I just wasn't sure if there was a clever way to use a random salt and random string without storing them plaintext on the server somewhere. If that's what you had in mind, I can certainly see how that would work.

Your point about the relative security of a system is a good one. Too often people view something as either "secure" or "insecure", when really it's a continuum, and each service should be designed with an eye toward the value of the information it's trying to secure.

____
Not the real rusty
[ Parent ]

Alas (4.50 / 2) (#26)
by sigwinch on Thu Dec 27, 2001 at 12:38:04 AM EST

I just wasn't sure if there was a clever way to use a random salt and random string without storing them plaintext on the server somewhere.
Alas, that particular wrinkle cannot be removed from the carpet. You can move it under the sofa, buy a heavier sofa, and hire a thug to sit on it, but the wrinkle is always there.
Too often people view something as either "secure" or "insecure", when really it's a continuum...
Absolutely! Forget that and you end up with a cardboard bank vault, or a gym locker with reactive armor.

There's a related lesson: even for a single user, different actions have different importance levels. Suppose a Scoop user has both special administrator and ordinary comment-posting privileges. These activities have vastly different importances, as well as different exposure to compromise. The admin password should be very strong, and never used on questionable machines. The user password need not be strong, and it's OK to expose it to a higher risk of compromise on suspicious machines. Therefore they should have different passwords.

--
I don't want the world, I just want your half.
[ Parent ]

Weird sofa-metaphor confluence (4.00 / 1) (#28)
by rusty on Thu Dec 27, 2001 at 01:00:05 AM EST

You can move it under the sofa, buy a heavier sofa, and hire a thug to sit on it, but the wrinkle is always there.

See my comment above. I swear I wrote that after your comment was posted, but before I had read it. Weird. Eerie.

____
Not the real rusty
[ Parent ]

I'm probably forgetting something obvious (none / 0) (#41)
by Ubiq on Fri Dec 28, 2001 at 11:44:02 AM EST

How about... using a block of random data (salt), calculating the hash of that, and encrypting both the block and the hash with the user's password. Every encrypted password would look different but can still be verified by decrypting the salt+hash and verifying if the salt matches the hash.



[ Parent ]
Ah-h-h-h (none / 0) (#42)
by Ubiq on Fri Dec 28, 2001 at 11:51:20 AM EST

The obvious thing I forgot is that this wouldn't help in the case of Blogger (because it needs to know the plaintext FTP password, because FTP doesn't do challenge/response). For other purposes it might work, though.



[ Parent ]
salts (5.00 / 1) (#23)
by pfaffben on Wed Dec 26, 2001 at 11:12:36 PM EST

What I can't figure out is how to keep the salt safe.
I am not an expert on encryption or authentication. However, this is what I understand: salts need not be safe or unobtainable in order to add security. Suppose we had no salt at all. Then an attacker could encrypt all possible passwords in a large dictionary and keep the results hashed into a file, and it would just be a matter of doing a quick lookup to crack any insecure password. But if there are 1024 possible salts, then the same kind of attack would require 1024 times as much disk space, which is probably impractical. Without a salt, it is also easy to tell when two users, by design or by coincidence, have the same password, which could obviously be a security risk as well.

So: whether your salt is safe or not, just its existence helps.

[ Parent ]

Oops, correction to use of block cipher (none / 0) (#43)
by sigwinch on Sat Dec 29, 2001 at 12:46:49 AM EST

You can also use any block cipher in CBC mode as the hash. Make the salt the first plaintext block, the password the next block (padded out to the full block size with untypeable characters), and the final cipher output is the hash.
What *was* I thinking? That's not a trapdoor function! Here's how it should have read:
Using the password as the key, encrypt the salt. The ciphertext is the hash.

Passwords smaller than the key size should be padded out to the key size using untypeable characters. Passwords larger than the key size should be collapsed using XOR.


--
I don't want the world, I just want your half.
[ Parent ]

Ummm.... (3.60 / 5) (#12)
by DesiredUsername on Wed Dec 26, 2001 at 07:15:21 PM EST

"It appears that Blogger stores users ftp passwords in plaintext..."

Doesn't FTP send passwords in plaintext? In which WhoTF cares how the *store* them.

Play 囲碁

Uhmm (5.00 / 2) (#13)
by Neuromancer on Wed Dec 26, 2001 at 07:25:23 PM EST

The difference between having to sniff network traffic and having to download a single file is kind of big don't you think?

[ Parent ]
nah (1.75 / 4) (#31)
by kubalaa on Thu Dec 27, 2001 at 06:56:35 AM EST

Counting on that is just security through obscurity. ;)

[ Parent ]
No it isn't (4.00 / 2) (#38)
by Neuromancer on Thu Dec 27, 2001 at 07:58:27 PM EST

No it isn't. To sniff the passwords in traffic passing through you would have to crack into a router that is peered with the source of the data. If it's ALL IP, you have to be in a router that is receiving the data. Aside from that you'd have to be on local ethernet with the person transmitting the passwords, which doesn't happen often these days since most networks employ network switches and routers rather than ethernet bridges. This means that you could only promiscuously sniff passwords on computers ethernet peered to you, which as I have already stated, is uncommon these days.

Barring that, you would have to crack into a router, and set it up to transmit all packets from the desired host to you. After that you would have to sift through the data and find the packet that matches the request response pair for the password handshaking in FTP. This would be all in IP packets mind you, not neatly formed tcp or protocol packets, so you would have to parse ALL of them to find the ones that you wanted. Bear in mind, that as I have already stated, you would have to have adminstrative access to this machinery to do this, whether or not you got it legally.

...or you could just download a plaintext file in a manner that would arouse VERY little suspicion. Sounds easier to me.

[ Parent ]
there's a big difference... (none / 0) (#44)
by phoenyx on Fri Jan 04, 2002 at 02:33:39 PM EST

...between sniffing out one password and grabbing a file with several thousand. Of course, if you are looking for one or two particular peoples' passwords, then it might seem a bit excessive to go for the file.

[ Parent ]
There's no point in encrypting the passwords! (2.66 / 3) (#15)
by mmcc on Wed Dec 26, 2001 at 08:40:37 PM EST

Since Blogger has to be able to get the plaintext back, using any encryption is useless, because the decryption key has to be stored in the same place as the encrypted passwords!

Looks like their security framework is broken simply because they need to keep their users' passwords. A better security model would be to have an applet on each user's machine that downloads the weblog data from Blogger.



Flawed proposal. (3.00 / 1) (#16)
by Holloway on Wed Dec 26, 2001 at 09:25:37 PM EST

I'm not up with my encryption, but wouldn't encrypting the ftp details using the password, and only storing the hash be a way of keeping keys off the server?


== Human's wear pants, if they don't wear pants they stand out in a crowd. But if a monkey didn't wear pants it would be anonymous

[ Parent ]
Yes (3.00 / 1) (#18)
by rusty on Wed Dec 26, 2001 at 09:28:46 PM EST

That's still breakable, but it would be a lot harder than exploiting an OS, web server, or database hole and just slurping down a SELECT full of plaintext passwords.

____
Not the real rusty
[ Parent ]
Two things (4.66 / 3) (#17)
by rusty on Wed Dec 26, 2001 at 09:27:12 PM EST

First, they don't force users to store their password on Blogger's servers. It's an option for convenience. I wasn't sure whether that was the case or not when I wrote the story.

Second, it does make a lot of sense to encrypt passwords. No security is perfect -- it's a matter of trying to make something as secure as appropriate. There are lots of ways to store encrypted passwords and a key to decrypt them on the same machine, while making it so that a compromise of one does not automatically mean a compromise of the other. The worst case, in that scenario, is that both are compromised, and then you end up with the situation they have now. There is, however a better case, where one is not compromised. Not encrypting them at all leaves you with only the worst-case scenario. It's generally better to go with the arrangement that requires more things to go wrong before you're fully compromised.

____
Not the real rusty
[ Parent ]

Re: Two things (5.00 / 1) (#19)
by mmcc on Wed Dec 26, 2001 at 09:57:32 PM EST

What you're talking about has a name: "Security through obscurity". The problem is that an attacker, knowing that Blogger uses plaintext passwords, knows that there must be a way to get those passwords after cracking Blogger's servers.

If they must stick with a broken setup like that, then i agree with you... it is slightly better to encrypt the passwords. However, it would be a much better idea to change their setup so that they don't have to know lots of plaintext passwords thus that having their machines breached doesn't result in a cascade of further security breaches.



[ Parent ]

Obscurity? (4.50 / 2) (#20)
by rusty on Wed Dec 26, 2001 at 10:14:50 PM EST

Nope, that's not security through obscurity at all. It can be well known that the blogger server encrypts passwords with Rijndael, for example, and it can be well known that the decryption key is on the server, in the file "/etc/blogger.key". An attacker simply knowing that information would not automatically compromise the security. They still have to go and actually break into the server, and figure out how to get sufficient privileges to read that file and grab the encrypted data. The security of a "keyfile" type arrangement relies on being able to guard root-level access to the server, not being able to keep the details of the setup secret.

Security through obscurity is an arrangement where the "security" of a security arrangement depends on the details of that mechanism's operation being kept secret. That is, "security through obscurity" would be, say, an arrangement where I relied on the fact that the key file is named "my_favorite_porn.txt" (but is world-readable) to keep the data secure. I'm sure you see the difference.

As Holloway mentioned, an even better arrangement would be where the plaintext (i.e. un-hashed) blogger password is used as part of the key to encrypt the FTP password, and the blogger password is only stored in hashed form on the server. So to recover the ftp password, an attacker first has to crack a particular user's blogger password, which can be made fairly difficult.

____
Not the real rusty
[ Parent ]

Re: Obscurity? (5.00 / 1) (#21)
by mmcc on Wed Dec 26, 2001 at 10:54:00 PM EST

    The security of a "keyfile" type arrangement relies on being able to guard root-level access to the server
I assumed that having a security breach meant somebody did have root access to their server.

If server must provide a plaintext password without user interaction, then somebody with root access will be able to determine that password. Note, checking a password is a different matter entirely.

As i said before, their security model is borken, not their storage methods. If the clients logged into the central server, not vice-versa, then their problems could be solved properly.



[ Parent ]

Risks (3.00 / 1) (#22)
by rusty on Wed Dec 26, 2001 at 11:01:42 PM EST

I assumed that having a security breach meant somebody did have root access to their server.

Not necessarily. I don't know the details yet of what exactly happened, but there are many thing that could have gone wrong without a full root compromise.

The security model, I can't speak to. The idea of Blogger is to make it easy for anyone to run a weblog on any webhost, which means that Blogger.com needs to be able to post updates to your (static) page wherever it may be. Basically, the user logs into Blogger, posts the blog text, and blogger turns around and posts it on your webhost, whatever it is. This of course has a whole set of risks associated with it, like for example, this. Hopefully in the future people will consider more carefully if the convenience of not having to enter a password every time is worth the kind of risk you take by storing a password someplace you have no control over.

____
Not the real rusty
[ Parent ]

Re: Risks (none / 0) (#24)
by mmcc on Wed Dec 26, 2001 at 11:30:19 PM EST

Yeah, i guess they're in a difficult situation, more so because their typical user is non-technical.

They'd probably have a difficult time changing the security model. Perhaps they could provide the option of storing the user's "blog" on their own servers? Probably too costly though.



[ Parent ]

They _do_ provide that option (none / 0) (#35)
by valeko on Thu Dec 27, 2001 at 06:55:58 PM EST

While the article failed to mention it by concetrating on the FTP side, Blogger has dual modes of operation - it can either FTP new entries to your static page on a different host, or it can keep the weblog in their own database, on their own machines. Most non-technical users choose this option.


"Hey, what's sanity got going for it anyways?" -- infinitera, on matters of the heart
[ Parent ]

What is obscurity (3.33 / 3) (#25)
by jasonab on Thu Dec 27, 2001 at 12:33:33 AM EST

Security through obscurity is an arrangement where the "security" of a security arrangement depends on the details of that mechanism's operation being kept secret. That is, "security through obscurity" would be, say, an arrangement where I relied on the fact that the key file is named "my_favorite_porn.txt" (but is world-readable) to keep the data secure. I'm sure you see the difference.
This doesn't necessarily apply to this situation, but I might add that there's nothing wrong with obscurity, per se. It's only a problem if that's ALL you rely on. It might be a good idea to name your password file my_favorite_porn if you then also encrypt it. That adds another layer of security to the system.

[ Parent ]
Hrm (4.00 / 1) (#27)
by rusty on Thu Dec 27, 2001 at 12:57:28 AM EST

There are two problems with obscurity:
  1. It's easy to forget that the obscurity you've imposed is like a paper shield, and think of it as "secure" when you meant to put something stronger behind it.
  2. It's easy to overlook something when you're dealing with security. Really easy. If you tell some other people about your security, they have a pretty good chance of thinking of a problem you didn't think of. If you plan to make all the details public, well, that's a lot of extra incentive to get it right.
Granted, both of these are kind of "social problems" -- they're problems in how we think, not inherent flaws in the security itself. But they are very common mistakes, and it's best to just avoid them altogether. As always, if you're not hiding anything of value, well just sticking it under the sofa is probably fine. But anything too important to be hid under your sofa probably shouldn't have any obscurity involved at all.

____
Not the real rusty
[ Parent ]
Name drop! (3.00 / 1) (#37)
by jasonab on Thu Dec 27, 2001 at 07:35:34 PM EST

Granted, both of these are kind of "social problems" -- they're problems in how we think, not inherent flaws in the security itself. But they are very common mistakes, and it's best to just avoid them altogether. As always, if you're not hiding anything of value, well just sticking it under the sofa is probably fine. But anything too important to be hid under your sofa probably shouldn't have any obscurity involved at all.
I took most of what I said from Secrets and Lies -- excellent book on all aspects of security by the famous Bruce Schneier. His basic point is to make the attacker's job as hard as possible. Things like make sure your web server is secure, but don't name it www on the network, and that sort of thing.

[ Parent ]
it's like big-O (none / 0) (#30)
by kubalaa on Thu Dec 27, 2001 at 06:54:59 AM EST

The point is that obscurity-security is SO weak in comparison to real security, that it's safe to ignore it in your calculations. The same way O(2n^2) and O(3n^2) algorithms are all just called O(n^2), because the other factors are miniscule in comparison.

So while you might do as you propose, it's generally agreed the time and confusion isn't worth the miniscule difference; if someone can crack your real security, the obscurity-security won't do jack.

[ Parent ]

Ev explains (4.50 / 2) (#29)
by Dries on Thu Dec 27, 2001 at 05:54:49 AM EST

Ev posted some clarifications on the BloggerDev mailing list. He writes as follows:
As most of you who were online today probably know already, Blogger was hacked yesterday (merry Christmas). I took it down this morning and have been investigating, etc, all day. I'm in the process of recovering and putting it back online now, but I haven't necessarily found the hole, so I'm doing so very cautiously. So, the API services have been down and will continue to be down until I'm able to tighten them up more, which probably won't be tonight (though I expect to have the main inteface back up tonight).

Sorry, Ev.

-- Dries
dDOS Spammer Sites (2.80 / 5) (#36)
by rawg on Thu Dec 27, 2001 at 07:22:31 PM EST

It would be cool if the people that hacked in would setup a dDOS against spammer sites like iFriends and the 1000's of others. I say knock them off the frick'n net. (I'm now getting 20 iFriends emails a day)

I'm using spambouncer.com and razor together and I still see about 5 spams a day. Someone save me! My spam box gets about 50 spams a day. My server is cranking out up to 200 spams a day. I need to start charging spammers for email server usage fees.

Missing a few things (4.00 / 2) (#39)
by philor on Thu Dec 27, 2001 at 11:10:02 PM EST

Couple three things that seem to be missing from this analysis: first, the only evidence for the "plain text password file" is Kottke asking why passwords weren't encrypted, apparently failing to realize that the Blogger passwords being compromised made FTP passwords available without access to the db (no, I'm not telling you how). Second, if it is so cheap and easy to encrypt the password file, wouldn't you think that Ev, who has been sitting on top of that fat file of cracker bait for 28 months now, would have done something about encryption? If it takes the average MeFi reader two minutes to figure out a scheme, surely even Ev could figure it out in a couple of years, which leads me to believe that either ftp passwords are encrypted, or he can't afford to encrypt them. Finally, picture yourself as Mr. Successful Cracker, with this awesome file of ftp logins and passwords, ready to wreak DDoS havoc. Is your first step going to be to change every Blogger password to the same silly thing, making it obvious that someone has been there, and making most of your nice new passwords useless? While I do understand the theory of assuming the worst in any security situation, in this case the most likely scenario seems to be that someone figured out a way to change all the Blogger passwords at once, and nothing more. That would make ftp passwords individually vulnerable, but I would hope that if Ev thought that the entire password file was snatched, he would do a little more than just "strongly suggest" that you change your password.

I don't know (none / 0) (#40)
by rusty on Thu Dec 27, 2001 at 11:50:01 PM EST

I was under the impression that it was a known fact that FTP passwords were saved plaintext. Sorry, rading over the MeTa thread, it seems that this was never proven.

...which leads me to believe that either ftp passwords are encrypted, or he can't afford to encrypt them.

Well, there's no case in which it wouldn't be affordable to encrypt them. The initial speculation about it being too resource intensive is just wrong. So, if you're right, then they probably are encrypted.

Ev says, on Blogger.com: "As mentioned before, however, we strongly recommend you change your FTP server password if you stored it on Blogger. (We have no evidence this information was accessed, but better safe than sorry.)"

That makes me to think that either the ftp passwords are not encrypted, or are pretty weak. I.e. he seems to be assumng that if the file was stolen (though they think it wasn't), then you'd be in danger if your password was among them. Normal caution? Hell, I'll email him and see if we can find out what the truth actually is. I'll be pleased to post an update here if it turns out they are stored encrypted.

Finally, picture yourself as Mr. Successful Cracker, with this awesome file of ftp logins and passwords, ready to wreak DDoS havoc. Is your first step going to be to change every Blogger password to the same silly thing, making it obvious that someone has been there, and making most of your nice new passwords useless?

Not likely, unless that step was somehow an important part of the overall exploit. I believe you're right, though, that that makes it look like the worst case may not have happened.

____
Not the real rusty
[ Parent ]

Ho, Ho, D'oh! Blogger Cracked for Christmas | 43 comments (40 topical, 3 editorial, 0 hidden)
Display: Sort:

kuro5hin.org

[XML]
All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
See our legalese page for copyright policies. Please also read our Privacy Policy.
Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
Need some help? Email help@kuro5hin.org.
My heart's the long stairs.

Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!