Realy great article about Hardware security tokens:

It contains a ton of information for people who want to learn a bit about modern security tools :)

Some "lessons learned" from the whole disaster:

1. Revoke keys when you notice the private key was compromised
2. Use HSMs to prevent private keys from getting compromised
3. Inform your customers about breaches
4. Do proper audit logging of your systems' user accounts
5. Use your own OS images, when installing machines
6. Run an IDS to get informed when your production systems act unusual
7. Spend more money on infrastructure security, less on marketing it

If you look for a hardening guide for your linux system, I can recommend "The practical linux hardening Guide" by trimstray.


1. It's based on SCAP policies.
2. It uses standards
3. It provides you with references and rationals, not just actions

This will allow you to consider whenever or not you should apply this configuration to your setup.

Ouch There are good reasons why you want to keep data within your infrastructure.

Every thirdparty can leak your data and then you have to clean the mess with your customers:

Example: Hosted was breached Hello fancy companies who have to tell me my data were exposed?

I wonder how many companies now bother to inform their customers.

So the Comodo forum was breached due to the vBulletin vulnerability that goes around recently.

They started their statement with:
At Comodo we take security very seriously and it is our highest priority.

I imagine the conversation like this: "We screwed up, " *lawyer checks the text* "We can't write this, we would make us liable in some way for this problem"

Why does our legal system (create the illusion to) punish those who tell the truth?

Mhm, I just decided to disable in my setup, but I neither consider it usable, nor safe to use.

1. I have no idea where the keys reside (and therefore how to make proper backups)
2. It turns of all indicators for signed and/or encrypted emails that enigmail provides, off and states that there is a recipient rule (which isn't shown in the UI)
3. I don't think people care enough about their autocrypt keys.


To be honest, the way of using `` being blocked by **unauthenticated**, regular DNS servers is the worst idea one could come up with.

It makes it trivial to perform a downgrade attack on any network and makes a lot of the promises DoH by default provides useless.

There are good reasons why we don't allow downgrades on other protocols, so why suddenly on HTTP?

The answer is as always "we don't want to break [wrongly setup] things".

And also a follow up on my traefik story, where an upgrade of the go version dropped the defaults for TLS connections down to SSLv3, instead of TLS1.0.

The wonderful team around traefik solved the problem and released a new version within 2 days:

That's how things should work!

Little follow up on my earlier statement about Desktop and the `--no-sandbox` argument they force on linux now.

I didn't just made noise on my social media but of course also (tried to) work with the upstream project. Sadly it seems like they don't care:

5 work days and no one even had a look at it. Great Maybe I should write a PR this weekend in hope it gets more attention.

Seriously, verify your systems after an update. Only continuous monitoring of security features will make sure you don't expose people to insecure systems over time.

This morning I had to notice that my traefik setup decided to downgrade its defaults to SSLv3 due to a bug in the go TLS library.

So yeah, if you run anything server-side that provides TLS and is build with go 1.12.x you might want to verify it.

If you wonder how I spend the last hour: Improving other people's container image build instructions.

Providing postfix with MTA-STS is a nice thing. But when you do it, please do it not as root

A container is no excuse to run software as root.


So electron improved their security features with the recent version 5, but by doing this broke tons of applications because they either need User Namespaces or an SUID executeable (to launch proper isolated subprocesses).

Desktop noticed this problem and as well and "fixed" it in the worst way possible:

On the other hand Desktop did a proper fix, which enables an SUID bit on this binary:


If you need to share a secret with me or just want to complain about an article or something else I said, here you go:

Get your message encrypted and ready in your email client to hit me, with 2 clicks!

Or copy the ciphertext and send it to me by any other messenger, it's up to you.

As always for the source code, here you go:

After @blacklight447 asked about my opinion on , I looked at their docs once more.

I remembered that they didn't convince me last time, I saw them, but I took the time now to write down a short analysis of what I figured out from their docs about the security status of this "Hardware password manager".

I really hope they proof me wrong, otherwise, it's a dumpster fire.

The Fedora Magazine published an awesome article about and it's abilities.

It's an easy to use and cross-platform, offline password manager.

Check it yourself :)

When you run Symantec or Norten AV, Microsoft will not provides security updates for now, because your Anti-malware solution, which at least according to itself, deletes all updates provides by Microsoft, which protect you from real security issues.

I mean, it's not like Microsoft announced months ago, that they will drop SHA-1 signatures this month And also SHA-1 support is already no longer recommended since years 仄 "Security experts"

Things get even better. So I opened a public GitHub issue in order to make sure people are informed and the developer might be even more motivated to fix it. Seems like the opposite is the case:

I'll give it another try to convince him, but if not 仄 Can't help people who don't want to be helped.

Since the way to the official @fdroidorg repository is still a bit complicated for , they decided to self-host a repository!

Want to get the Bitwarden Android app without Google Play? Here you go:

And here we go, my new blog article is out:

"Atom plugin "gitlab-integration" leaks your tokens"

TL;DR: When you use the Atom plugin gitlab-integration you should either patch it with the mentioned workaround in the article or stop using it. Definitely you should revoke the personal access token you were using with it.

Remember Spectre? It's back!

Time to patch your systems!

This time it's called Spectre SWAPGS and has the CVE number: CVE-2019-1125

Have fun!

Show more

Sheogorath 's choices:

Sheogorath's Microblog

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!