Once you get over a trivial number of friends - once you have more than one social circle - Twitter doesn't scale at all. If I send a public reply, my followers get it... but don't have the context originally.
So, it works well, until you get beyond one social circle, and then the whole thing goes to hell. It's great for shouting something to a larger group (at the Sharp Edge Beer Palace!), great for content-free posts (I'm pooping!), but terrible for conversation.
It's interesting to see that both Google Buzz and Facebook Status Updates address this; you have well-threaded replies that don't ping your followers unless they were one of the repliers. Buzz scales better than Facebook; Facebook defaults to emailing you further updates, while Buzz simply bumps replied-to responses that you previously replied to to the top of your stack.
Dunno. I still don't understand Twitter. A friend mailed them a (relatively huge) public security bug three or four years ago, which took them the better part of three or four years to fix. (An http: should have been an https: when pointing at Gmail.) Not impressed?
Twitter vs Buzz vs Facebook updates
Encryption Strength
Got into a discussion today where I was asked to compare various forms of encryption against each other. This is pretty much the long-form verbatim reply, which was interesting enough to post:
First off, there are two main categories of encryption algorithms; symmetric and asymmetric. A symmetric algorithm is like a decoder ring; both people have the same key. Taking the postal service as the example, the sender uses a key to lock a package, the package is sent to the receiver, and the receiver uses a copy of the same exact key to re-open the box.
An asymmetric algorithm is a bit of magic; the sender has a public key, and the receiver has a completely different private key. The classic example is that the reciever first sends the sender a lock in the mail, then the sender will lock the package before sending it back. Said another way, the receiver creates both of the keys, and only gives out the public one, which allows encryption, but does not allow decryption. Asymmetric algorithms are also called "public key" cryptography, since they have a public key that may be freely distributed.
Both have advantages and disadvantages. Symmetric encryption can have much smaller key sizes, and because of that, it runs more quickly. Asymmetric encryption runs slowly, and requires large keys, but gives one more layer of security: the private key, required to decrypt any message, has never been sent to any other computer other than the receiver's. In symmetric encryption, if someone gets the key, you need to change the locks; if they get the key and had previously made a copy of your encrypted data, they have your data.
Skipping a bit of the technical details, for symmetric encryption, the US Government uses the AES algorithm, which offers 128, 192, and 256-bit key strengths. Smaller keys are quicker to build and can encrypt/decrypt data faster. Larger keys are exponentially harder to break. AES128 is expected to last at least through 2030; AES192 or AES256 are required by the government for Top Secret information. If the data is going to be important for more than 20 years, consider going with one of the larger key sizes.
RSA is one of the most popular asymmetric algorithms; DSA is another. Digging into a NIST recommendation from 2007, 2048-bit RSA keys will be breakable around 20 years from now, and 3072-bit RSA keys are believed to be equivalent to 128-bit symmetric keys; 15360-bit RSA is both *huge*, and roughly equivalent to a 256-bit symmetric key. From my understanding, RSA and DSA are roughly equivalent in this regard.
Anyways, my knowledge runs down a little bit where the rubber hits the road on this one. My understanding is that Apache's mod_ssl is effectively maxed-out at a 1024-bit RSA key, since not all versions of Internet Explorer will accept a larger key. That's equivalent to - give or take - an 80-bit symmetric key, which will be broken in the next few years; certainly in the next 20. As an important caveat, "broken" means that that particular key was broken; not all keys of that strength. It takes a few million years of CPU-time to break a 1024-bit key, but modestly-sized malware botnets could be utilized to break those keys in days with today's technology.
The (layman's) takeaway: SSL in browsers isn't strongly secure, and other forms of encryption should probably be used for secure data that needs to travel outside of a single corporate network, or that needs to remain secure for more than twenty years.
As a new variant, there are also "elliptic curve" asymmetric algorithms that use far fewer bits, and are used for securely hashing and signing documents; SHA-256 and SHA-384 seem to be about equivalent to AES-128 and AES-192.
Sort Algorithms
Okay, this one makes me happy. New algorithms - new applications of theory - that I can actually use seem few and far between, but I just ran into one.
David Musser's Introsort is an algorithm from the late 90's that starts with quicksort, and switches to heapsort if quicksort isn't expected to perform well on the actual dataset. It has the speed of quicksort, but in a worst-case-scenario, it only falls back to O(n log n), which is awesome. (Quicksort's worst case is n^2)
So, why would that matter?
Well, if you're maintaining an important server that contains lists of data, and the server sorts incoming data to store it, an attacker could send you a list designed to really, really ruin your day. A DNS server might be a decent example of this. Or even a payment gateway that sorts by customer ID before it gets going.
Windows 7 Password Reset
So, the reason I needed Knoppix was that I installed Windows 7... and was locked out on reboot. I'm assuming I fat fingered the password. Moving on.
My first try was ophcrack; it's a bootable ISO that starts the machine, finds all the user accounts, and runs the passwords against a rainbow table. It has two versions; XP and Vista/7. I'm running this on a netbook, so I installed the ISO to a USB key with the Universal Netbook Installer, which might be the best open source app I've seen recently. Unfortunately, ophcrack didn't work.
I found an older Knoppix boot CD; Knoppix is a version of linux that fits on one CD, and runs off of CD; it doesn't install to the hard drive, although it allows you to access the files on the hard drive. I had a little problem with my network, and then was able to move onto fixing the problem.
- Download chntpw from Debian; http://packages.debian.org/unstable/admin/chntpw
- Convert the deb file to a tar: alien --to-tgz
- Unpack the tar: tar xvzf
./usr/sbin/chntpw
- Move the executable somewhere handy: mv ./usr/sbin/chntpw ~
- Mount the hard drive. For Windows 7's default install to /dev/sda2: mkdir /mnt/disk; mount -t ntfs -o uid=Knoppix,gid=Knoppix /dev/sda2 /mnt/disk
- Change to the directory of the file with the passwords: cd /mnt/disk/Windows/System32/config
- Copy the password file, just to be safe: cp SAM /mnt/disk/
- List the usernames available to change: ~/chntpw -l SAM
- Erase your password: ~/chntpw -u
- Change directory out of the Windows 7 partition: cd
- Unmount the Windows partition: umount /mnt/diskd
- Reboot; you're done.
There's probably something to be said here about "physical security". On the plus side, this only blanks a password, so if someone uses this to get your data, you'll at least have a hunch at what happened.
In the meanwhile, it's time to create myself a password reset disk. (Apparently, Control Panel, search for "Password Reset", and have a USB key in the computer.)
SSH Problems
So, I've written about automatically logging in with stored ssh keys and also about the Linksys NSLU2 Slug with Debian. Today, the combination of the two are important, as CERT alerted me to a new security hole in Debian and Ubuntu, and the fix for it.
When an SSH key is created, it generates a random number, and then builds the key based on that number. The problem is that the random number generator in Debian wasn't producing completely random numbers, and that meant the secure keys aren't completely random, and aren't completely secure. Ubuntu is based on Debian, so this applies there as well.
Anyways, the fix is simple enough; update the machine, and re-generate your keys.
PHP SOAP Continued
So, continuing from my last post, there's a missing chunk of documentation for PHP::SOAP, especially when it comes to interacting with .NET SOAP Servers. It's especially odd, because SOAP is one of the places where Microsoft seems to have written their code to exactly meet the standard; the problem probably isn't on the Microsoft end of things.
Again, we shut off the WS-Security specific to SOAP, and only used HTTP Authentication, by the customer's request. It seems that WS-Security uses a call to $client->setCredentials($user, $pass, 'basic), whereas HTTP Auth requires user/pass in the instantiation of the SoapClient.
Anyways, here's the example:
$user="bob";
$password='bobspassword';
$wsdl = "https://".$user.":".$password."@example.org/ws/supervisors/?wsdl";
$client = new SoapClient($wsdl, array("trace" => 1, "exceptions" => 0, "login" => $user, "password" => $password));
// Debugging information to show all functions described in the WSDL
$functions = $client->__getFunctions();
print_r($functions);
$types = $client->__getTypes();
print_r($types);
print "
";
// Call the SOAP service
$params->empId= "12345";
$response = $client->EmpToSuper($params);
// Display more debgging information
print_r($response);
print "\n";
";
// Display the request that was sent out
print "Request :\n".htmlspecialchars($client->__getLastRequest()) ."\n";
// Display the response that came back
print "Response:\n".htmlspecialchars($client->__getLastResponse())."\n";
print "
?>
Password Security
Doing some helpdesk support for coworkers, it's unusually hard to explain to some folks why they have to keep their passwords secure.
In short, it's fine to write a password down, as long as you protect that slip of paper like you'd protect, well, other important slips of paper, like a $100 bill. Keep it in your wallet, keep your wallet with you at all times, and you're good, unless the password is much more important than any amount of money you'd ever carry.
It's not fine to write a password on a post-it note and stick it to your monitor. Other people can and will sit at your desk, can and will read the post it notes directly in front of them, and eventually will use your password without your permission. It's also not good to hide those passwords in a drawer in your desk... because if someone then wants to login as you, all they need to do is shuffle through your papers when you're not there.
This seems, well, trivially simple to me. If you can't remember passwords, it's O.K. to write them down, but not okay to write them down where other people *will* find them.
Automatically logging in with SSH
I've done this dozens of times, but always forget, so it's time to do it in a slightly more robust manner.
When I ssh from machine A to B, it asks for a password. With public-key authentication, it's possible to set this up so it doesn't need a password to verify I am who I say I am. If I'm running scripts on a machine automatically that connect to another machine - say, for an rsync backup - I just want the scripts to run, not to have to stop for user input of a password.
Doing this takes a few steps... but is pretty darn easy. For two machines, client and server...
- Create a public ssh key on the client machine. You might even have one already. The directory where ssh stores it's files is ~/.ssh. The public key would be called either id_dsa.pub or id_rsa.pub. If neither of those files are there, create one by typing "ssh-keygen -t rsa". Save the file in the default location, and enter no passphrase. (If you enter one, you need to retype it every time you use this key, which defeats the purpose in this case.) This should create a 2048-bit RSA private key.
- ssh is very, very particular about the permissions on the ~/.ssh directory, and for some operating systems (OS/X, Cygwin), the permissions often aren't already set correctly. "chmod 600 ~/.ssh" should do the trick, giving just the owner of the directory read and write access. I usually skip this step, and if an error occurs, come back to it.
- We need to copy the public ssh key (~/.ssh/id_rsa.pub) to the remote server, and append it to the authorized keys file (~/.ssh/authorized_keys, on the server). This should do the trick: "cat ~/.ssh/id_rsa.pub | ssh remoteuser@remoteserver.com 'cat >> .ssh/authorized_keys'" Be careful to copy id_rsa.pub, and not id_rsa; the latter is your private key, and you shouldn't copy it anywhere!
The main security problem I see with this is that if someone else has root or administrator access on a machine you've set up as a client, they can log into the server as you. If anyone gets access to your private key, they can also log in as you. Do *not* give out the private key.
