Tag: security

Own your own credentials!

Login with Google. Login with Facebook. It’s convenient. No need to invent and remember a new username, a new password. It’s almost a single-sign-on (SSO) to the entire internet.

The obvious downside, however, is that within a second you could see yourself locked out of many of your accounts. Just imagine that for some reasons your identity provider (Google, Facebook, Apple, …) decides that you have violated their terms of service. And locks you out of your account, and as a consequence also of all the services that you used the account for. Too few people consider this, in my opinion. It can happen quite fast (recent example involving AI).

Of course you can then try to fight this lock and argue your way back into the account. But you need to be very lucky to even get some human’s attention on the other side. Unless you somehow manage to make a huge buzz on it on (social) media, I bet your chances of getting the issue resolved are pretty thin. Google is even proud that you can’t call them in order to sort this thing out (see Google’s Account Recovery support page; yes, they are right that you should not use any external password recovery service).

Don’t get me wrong. I love SSO in a company context. But there is an admin that I can talk to in case something goes wrong, and if my account is terminated, it likely is because my employment is terminated. I just don’t like it for my personal data, where some (perceived) violation of some terms of service of one of the big companies might lock me out of all my other unrelated accounts as well.

I very strongly believe, that anyone making themselves a gatekeeper for things outside their own business should be, by law, required to not terminate your account without any recourse. Yes, they can stop doing business with you. But they should not be allowed to stop authenticating you.

Passkeys as alternative?

For a while, it seemed that Passkeys would become a convenient and secure way of signing in to services. I, however, only started to consider them once KeepassXC with 2.7.7 started offering support for managing them inside the password store, so that I could backup it and would not be depending on a hardware device that could break or that I could lose.

Unfortunately, it really seems that the big companies are using this technology yet again to lock you in their ecosystem, creating exactly the same problem for me as I have with the “Login with…” system. The following articles are a very good summary of what went wrong and also why the current standard and the insistence to resident keys have made this system basically unusable for the concerns I mentioned above.

Maybe good support in password stores (like Bitwarden/Vaultwarden, KeepassXC, Keepass2Android) can maybe still make this a viable alternative. The cryptographic advantages of passkeys over normal username/password are great, so I really think it can be an improvement in the future.

Staying with usernames and password manager (for now)

For now, I’ll still stay with my own setup using my self-managed password stores. With all the work and dangers this incurs as well (backups, distribution, availability).

To quote from the article mentioned above, something that I can absolutely endorse:

And I’m starting to agree – a password manager gives a better experience than passkeys.

That’s right. I’m here saying passwords are a better experience than passkeys. Do you know how much it pains me to write this sentence? (and yes, that means MFA with TOTP is still important for passwords that require memorisation outside of a password manager).

So do yourself a favour. Get something like bitwarden or if you like self hosting get vaultwarden. Let it generate your passwords and manage them. If you really want passkeys, put them in a password manager you control. But don’t use a platform controlled passkey store, and be very careful with security keys.

Add SSH host key fingerprint to Jenkins for Git checkouts

I have a self-hosted Gitea instance, and also operate my own Jenkins instance. On the Jenkins instance, strict host-key checking is enabled. When adding the first reference to a Git repository hosted on my server, the following error appears:

Failed to connect to repository : Command "git ls-remote -h -- ssh://git@<myserver>:22222/martin/jenkins-test-docker-pipeline.git HEAD" returned status code 128:
stdout:
stderr: No ECDSA host key is known for [myserver]:22222 and you have requested strict checking.
Host key verification failed.
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

The reason is that since it’s the first time I’m accessing a repository on this server, so the SSH host fingerprint is not in the known_hosts file for this SSH connection. Since I run this installation of Jenkins inside a Docker container and I don’t want to manually edit files in the file-system, I rely on setting the appropriate settings in Manage Jenkins > Security > Git Host Key Verification Configuration. This is set to Manually Provided Keys.

The easy solution is to set it to Accept First Connection. But I want to be stay on the manual mode. The easiest way to get the SSH host fingerprint via ssh-keyscan (-p 2222 is for specifying the SSH server port, which is a non-standard port in my case):

ssh-keyscan -p 22222 myserver

The output looks like this:

# myserver:22222 SSH-2.0-OpenSSH_9.1
[myserver]:22222 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC085ixMnTlpr0pxXmkeJ6X479mbW/9PGDeUvD8hnG7EVUn3WsnnSG8yZkmU+jzg2W+xmFd7WIdaYLt6UcGvCS3RZIye68+qu64UToKX6CdTQOWyj6z9kd8tLoPBobsBd7tRyGaXU4c4UkCR5M44KhYtbQz0bgL7u+sL0z+R3lbOVyXaYPiSmUf/Wsd8fA2VcdWHkXJx0MMNMSVj/hgkZR7RfHzP4SZSqRLhn/AzIdx4DDuyGyPbVxu1ppnFtumRwlBkgat9UpMWkelREhcUdJtrZO1KPpA6DOkxIH8X/WtXyWToS9EjPb8FVTvzdjG2C4Zi0DkogH3no9vQcXLiihz
# myserver:22222 SSH-2.0-OpenSSH_9.1
[myserver]:22222 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBDfTT9eEpDmd7ToGAorTW1X9uuJVhZl+KX9phmTpTy2e8U7l31jWn2TnKlXOp5oKgivpQ2cVjcTyazyrFB7MhgI=
# myserver:22222 SSH-2.0-OpenSSH_9.1
[myserver]:22222 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFoEzPpEWApszceLM/jWHvAbrTppjsTzftw79yTSS5Po
# myserver:22222 SSH-2.0-OpenSSH_9.1
# myserver:22222 SSH-2.0-OpenSSH_9.1

It only makes sense to copy the non-comment lines (the ones not starting with a # to the configuration).

Now Git checkouts to this repository should work, once you have configured the appropriate credentials.

Enable RSA-based public-keys for ssh when accessing legacy devices

When accessing old devices that are not yet using modern encryption algorithms, current Ubuntu installations might reject connection due to the signature algorithm for the public keys being disabled, e.g.

sign_and_send_pubkey: no mutual signature supported

You can enable this on a per-command level by adding the following option to your SSH command line:

ssh -o PubkeyAcceptedKeyTypes=+ssh-rsa ...

As an alternative you can add this permanently for a host by adding it to the host’s configuration in your $HOME/.ssh/config:

Host myhost
  PubkeyAcceptedKeyTypes +ssh-rsa

This also works for other key types like ssh-dss.

Note: In general you only should do this if you access legacy devices where you have no possibility to upgrade to state-of-the-art encryption algorithms. Those algorithms got deprecated for a reason. Therefore always do this on a per-command or per-target-host level instead of blindly enabling those algorithms in your global SSH config.

URL shortening services soon to be under siege?

I have already written about my opinion about the problems of URL shortening back in 2005. Yesterday, Jeff Atwood pointed out other issues like commercialization. Today, another threat has come true: hackers have manipulated the URLs of shortening service cli.gs.

Given the huge amount of information hidden behind such shortened URLs, and given the popularity and number of these links, especially nowadays on Twitter, these services could see themselves being under permanent siege of hackers/crackers. Being able to manipulate hundred of thousands if not even more vastly distributed and popular URLs to point to a given site could be used for both, generating (lots of?) ad-revenue, or as a new form of DDoS-attack.

At the moment there seems to be no way around using these services (especially with services like Twitter), but in the medium/long run a solution has to be found if we don’t want to lose lots of valuable information.

TrueCrypt 5 is out!

ImageAfter quite some time, a new version of my favorite encryption tool is out: TrueCrypt developers have released version 5 of their product, introducing a new killer feature (among others): System Volume Encryption with pre-boot authentification (only Windows 2000/XP/Vista). This means, that TrueCrypt will encrypt everything on your system drive, including page- and hibernation file, finally making hibernation a safe and easy possibility.

I am going to look into this next week, as I need my notebook on Saturday (just in case anything goes wrong).

Update 2007-02-08: As my first commenter below points out, it seems hibernation is disabled by TrueCrypt while having your system partition encrypted. I don’t really understand why at the moment, but I will investigate further. For me this is a primary show-stopper, as this was the long-awaited functionality I was waiting for.

Nitpickers Corner¹: Of course I am aware why encryption and hibernation in general are no-goes together, but I don’t understand why this is an issue when full-system encryption is enabled.

Update 2007-02-08 (again): Ok, in this TrueCrypt forum thread they explain why they cannot support it at the moment: Windows treats the hibernation file differently, it seems to bypass the TrueCrypt driver and therefore would still write keys to disk without encryption. Ok, still get to wait for my dream feature then, but I still refuse to buy PGP 🙂 Thanks to the developers for their great work anyhow!

¹ a tribute to Raymond Chen 🙂

[tags]security, encryption, truecrypt, windows, linux, osx[/tags]

The Storm Worm

I want to point out a very interesting article by Bruce Schneier about the Storm worm. If it were not so illegal, the techniques used by this worm are very, very advanced and very interesting from a development and network/load-balancing point-of-view. Anyone interested in development, network administration, and security should read the article.

The worm has grown to a real epidemic by continuously adapting, changing its code, the code signature, etc. It has infected this huge number of computers because the resulting bot-net is hardly ever used, it keeps in a dormant stealth mode. Most users are not aware they are infected with the worm because it tries to avoid detection by not using to much ressources and therefore hardly attracts attention by system administrators. Bruce Schneier points out that maybe we should be worried about what’s coming in “Phase II”, once the gigantic bot-net is brought into action.

To avoid detection, the worm and the bot-net operators apply several advanced load-balancing and stealth techniques, namely a DNS technique called “fast flux” which very effectively blurs the traces to the real operators.

As I said, it is very interesting read. I recommend you also follow several of the outbound links.

Affordable offsite automatic backup for Windows and MacOS

I just discovered Mozy (via TechChrunch), a service for automating the backup process by automatically storing all your data encrypted on their server for backup purposes. It is a Windows software that automates the backup process and provides secure online storage. According to the specification you can either use their encryption key or provide your own public key for the encryption.

Mozy comes in two flavors, a version for home-users which they call MozyHome (4.95$/month for unlimited storage) and a service for businesses, called MozyPro, which bills 3.95$ per computer, but also 0.50$/GB per month. I think the service would definitely be interesting but the storage costs seem to high for me. There is also “MozyHome Free” which provides you with free 2GB of backup storage. Maybe the recent purchase by EMC Corporation will change the pricing list (honestly, I don’t think so…)?

The idea of storing my confident data or even corporate data on remote servers not under my control is a little bit frightening, but in case you are able to believe they have not built a master-key in the software, it might be a nice option for offsite backups which definitely everybody should use. Maybe one should give the “MozyHome Free” a test-drive… Too bad there is no Linux version available.

If I can convince myself to try out the “MozyHome Free” I will write another report here.

.NET strings are not always immutable!

Strings are immutable. If you want to modify a sequence of characters, use StringBuilder. At least, that’s whats officially said. But in the framework there is at least one method that does modify a string:

TextRenderer.MeasureText() with ModifyString and EndEllipses will modify your string to match the ellipsed text if ellipsing happens. You can look at this VB# example on codeproject using TextRenderer.MeasureText() for trimming text on how it is used.

The string seems to be modified directly in native code by DrawTextEx from user32.dll. Additionally to the scary fact that strings are not immutable, the length of the string is not updated, regardless if the resulting string is shorter!

For instance if you have a string “aaaaaaa” which will be truncated to “aa...“, the Length property will still return 7 for the shortened string. The debugger shows that the string will in fact be “aa…\0a” after the operation. So maybe it might be right that the string is still 7 characters long but most outputting functionality like Console.Out.WriteLine() gets confused sometimes and stops any further output to the debugger or console under certain conditions.

A very quick investigation of the System.Drawing assembly using Lutz Roeder’s fabulous .NET Reflector showed that at least there should be no memory corruption in case “WW” would get ellipsed to “W...“, as DrawTextEx takes the length of the buffer and should result only in “W.“.

Summing up, I find the corruption of an immutable string by an official Microsoft API very troubling.