alexbakker

Correct.

You're right, it's been a while, but we actually issued a beta release for 2.1 today!

There's a third option to switch from Google Authenticator to Aegis. You can simply scan those export QR codes of Google Authenticator with Aegis.

Aegis is fully offline and doesn't have an official desktop application. You could of course create an export of your Aegis vault and import it in a third-party desktop application, like GNOME's Authenticator or OTPClient.

It's just a group name for the two guys working on it. Source: I'm one of them (Hi!)

This is amazing work!

I was surprised to see that the reward was set at 10k initially. Granted, it was bumped to 75k later, but even that seems on the low side considering the degree of compromise that occurred here.

I may have given up too early during my (fairly brief) research on CVE-2019-9465. I let the lack of firmware source code availability stop me at the time, but in hindsight the presence of "0dd0adde0dd0adde" in the ciphertext likely indicated a crash in Titan M as well. Perhaps there would have been a similarly interesting path to exploitation there.

I'm seeing this as well. While the amount of traffic has certainly decreased compared to the first couple of days after the CVE was announced, https://log4shell.tools is still being used by people every day.

Glad to hear you like it!

> android.permission.INTERNET is frankly hilarious since that permission no longer does anything (every app has access to the internet).

This is incorrect. If an app doesn't specify this permission in its manifest, it cannot access the internet.

It sucks to see your open source work being abused like this, and there's seemingly nothing we can do about it.

Every now and then I scour the play store to see if I can find any Aegis clones. We've reported a couple that didn't have a link to the source code and/or were linking proprietary libraries (as per our license), but they're still up. Of course, those cases aren't as bad as this one where actual malware was included, but it's pretty telling about the state of the Google Play Store.

You're right, but this has always been the trade off with tools like this. You put some trust in the tool's authors and gain some insight in return. Remember the services that tested for Heartbleed (e.g. https://filippo.io/Heartbleed/)? Fairly similar trade-off, but still these tools were widely used.

If you don't trust me and have some technical know-how, you can self host the service. It's open source: https://github.com/alexbakker/log4shell-tools.

I can't say I'm feeling the same. Still lots of people testing over at https://log4shell.tools almost a week after this vulnerability became widely known. Plenty of people still discovering they're vulnerable as well. I think it's likely that these are just the people who know they're using log4j. If you're running a black box product from some vendor you'll have no clue you're vulnerable until it's too late.

You're welcome! I'm glad you find it useful.

I have a feeling this vulnerability is going to be with us for years. Shameless plug: I built a tool that assists in detecting whether you're vulnerable to this or the previous CVE: https://log4shell.tools. Just enter the JNDI URI it gives you anywhere you suspect it ends up causing a message lookup in log4j. If log4j does so much as a DNS lookup, this tool will tell you about it.

If you write down the secrets and the other parameters on paper, that would suffice as a backup as well. I'd recommend using Aegis' encrypted backup though.

One of the authors here. We've gotten a lot of similar feedback lately. This is something we plan on addressing in a future release by introducing filter chips, either directly on the main view, or one tap away. Hopefully that'll make it a bit easier to quickly filter based on groups.

One of the authors here. Yes! Aegis can scan the QR codes that Google Authenticator presents in the "Transfer accounts" screen. It's also possible to import directly from Google Authenticator's internal database if you have root access.

One of the authors here. Recent versions of Aegis also come with an automatic backup feature, so that an export is created at a location of your choosing automatically every time a change is made to your entry list. Might be a little more convenient than doing manual exports every time.

Thanks for your support! That's a fair point. We'll see what the feedback is like when we release initial support for icons packs and decide whether to include a pack out of the box after that.

One of the authors here.

Unfortunately, Google Drive and Dropbox only partially participate in Android's Storage Access Framework. In Aegis, exporting only requires the creation of a file, so that works with both. Configuring backups on the other hand requires selecting a folder, but most cloud providers don't support that. A notable exception is Nextcloud.

One of the authors here.

> Icon library for common websites using OTP

Someone from the community is maintaining an icon pack for Aegis: https://github.com/aegis-icons/aegis-icons. We're currently working on making icon packs easier to use in Aegis, see: https://github.com/beemdevelopment/Aegis/issues/509.

> Maybe Steam OTP support

Steam is supported, actually! But like you said, you'd still need the Steam app if you're doing trading.

Author here. I should have made this clear in the blog post, but I'd be interested in seeing boot logs from Pixel 3 (or newer) devices. If the firmware update failed on more devices than just mine, it would be good to know about that. If you'd like to help, first make sure you're at least on the December 2019 security update. To capture the log plug your phone into a computer, run "adb reboot ; sleep 1 ; adb logcat | grep -i citadel" and turn the phone back on. Wait for it to boot, unlock the SIM card and unlock the screen. This should yield the version information of the firmware of Titan M.

The big question is indeed how many devices got themselves into this 'bad state'. Your guess is as good as mine.

You're absolutely right about the excerpt. Fixed, thanks.

One of the Aegis developers here. Thanks for the feedback. Could you create an issue on GitHub for #2? I'm curious to know if you killed the app or just minimized it.

Why wouldn't it be? Why would a compiler know what a signal handler is?

Odd, this doesn't appear to apply on my 2500K even though it's listed as "valid for this product":

  [    0.000000] microcode: microcode updated early to revision 0x29, date = 2013-06-12

Works fine on my 7200U though.

>go needs go

No it doesn't. You can use gccgo to bootstrap go.