🆕 Software Suggestion | Aegis Authenticator #1956

New Issue

2020-06-17T06:41:51Z

lynn-stephenson commented

2020-06-17 06:41:51 +00:00

(Migrated from github.com)

Basic Information

Name: Aegis Authenticator
Category: 2FA Authenticator
URL: https://getaegis.app/

Description

A free, open source, and easy to use Android 2FA application distributed on F-Droid, and Google Play Store.

Why I am making the suggestion

Currently there isn't a recommendation for software based two-factor authentication, and this is one of, if not the best executed solutions.

My connection with the software

I'm not the author. But I have analyzed the design (which was far easier due to amazing documentation by Beem Development). In turn I've found no critical issues, I find the software trusty, so I am a user of it.

I will keep the issue up-to-date if something I have said changes or I remember a connection with the software.

## Basic Information **Name:** Aegis Authenticator **Category:** 2FA Authenticator **URL:** https://getaegis.app/ ## Description A **free**, **open source**, and **easy to use** Android 2FA application distributed on [F-Droid](https://f-droid.org/packages/com.beemdevelopment.aegis/), and [Google Play Store](play.google.com/store/apps/details?id=com.beemdevelopment.aegis). ## Why I am making the suggestion Currently there isn't a recommendation for software based two-factor authentication, and this is one of, if not the best executed solutions. ## My connection with the software I'm not the author. But I have [analyzed the design](https://github.com/lynn-stephenson/analysis/blob/master/Aegis%20Authenticator%20v1.1.4.md) (which was far easier due to [amazing documentation](https://github.com/beemdevelopment/Aegis/blob/master/docs/vault.md) by [Beem Development](https://github.com/beemdevelopment)). In turn I've found no critical issues, I find the software trusty, so I am a user of it. - [x] I will keep the issue up-to-date if something I have said changes or I remember a connection with the software.

👍 19

beerisgood commented

2020-06-17 11:19:50 +00:00

(Migrated from github.com)

Same like andOTP.

John3 commented

2020-06-17 14:48:40 +00:00

(Migrated from github.com)

Same like andOTP.

Yes and no 😆 is better and should be included, from my pov his code is more secure, even the guy discovery a bug in the titan module which has already been fixed.

> > Same like andOTP. Yes and no 😆 is better and should be included, from my pov his code is more secure, even the guy discovery a bug in the titan module which has already been fixed.

🚀 1

lynn-stephenson commented

2020-06-17 17:26:56 +00:00

(Migrated from github.com)

Same like andOTP.

Although AndOTP is similiar, I've found issues with it, and so has the developer(s) of Aegis Authenticator.

Although these issues were easy fixes. Most of them were fixed.

For me, I find Aegis easier to use. It supports a wide range of other authenticators. And doesn't have the same loss of vault issues with using the key store that AndOTP has.

> Same like andOTP. Although AndOTP is similiar, I've found issues with it, and so has the developer(s) of Aegis Authenticator. Although these issues were easy fixes. Most of them were fixed. For me, I find Aegis easier to use. It supports a wide range of other authenticators. And doesn't have the same loss of vault issues with using the key store that AndOTP has.

beerisgood commented

2020-06-17 18:46:00 +00:00

(Migrated from github.com)

For me, I find Aegis easier to use. It supports a wide range of other authenticators. And doesn't have the same loss of vault issues with using the key store that AndOTP has.

What? andOTP itself doesn't have problems with Android key store. I use it in this way and don't get any problems. Did you have any more info?

> For me, I find Aegis easier to use. It supports a wide range of other authenticators. And doesn't have the same loss of vault issues with using the key store that AndOTP has. What? andOTP itself doesn't have problems with Android key store. I use it in this way and don't get any problems. Did you have any more info?

ph00lt0 commented

2020-06-17 20:57:23 +00:00

(Migrated from github.com)

Backup system is often not working (like in the last version) that is really a pain. It feels a lot more stable and doesn't crash all the time like andOTP.

John3 commented

2020-06-17 21:29:34 +00:00

(Migrated from github.com)

Backup system is often not working (like in the last version) that is really a pain. It feels a lot more stable and doesn't crash all the time like andOTP.

what? 😅 Untrue! at least for me never failed, 😄 I have maybe 30 2fa configured 🤣 the backup system never failed or the app, very reliable.

Actually I used the backup system in all the last betas/releases, I needed to change my phone two times plus a factory reset 😕 I'm pretty sure from v1.1.3, v1.1.4, v1.2-beta1 to v1.2-beta5 and v1.2 stable for me the backup system worked. I did encrypted export and import every time in this versions plus automatic encrypted backups.

> Backup system is often not working (like in the last version) that is really a pain. It feels a lot more stable and doesn't crash all the time like andOTP. what? 😅 Untrue! at least for me never failed, 😄 I have maybe 30 2fa configured 🤣 the backup system never failed or the app, very reliable. Actually I used the backup system in all the last betas/releases, I needed to change my phone two times plus a factory reset 😕 I'm pretty sure from v1.1.3, v1.1.4, v1.2-beta1 to v1.2-beta5 and v1.2 stable for me the backup system worked. I did encrypted export and import every time in this versions plus automatic encrypted backups.

👍 2

ph00lt0 commented

2020-06-17 21:39:09 +00:00

(Migrated from github.com)

I have about 50, and only the auto backup works now, manually always crashes the app. And check issues on their github, I am not the only one, maybe people are facing issues with it. Maybe you should look into things before using an extreme amount of emojis and calling someone's comment 'untrue'.

lynn-stephenson commented

2020-06-18 01:01:30 +00:00

(Migrated from github.com)

For me, I find Aegis easier to use. It supports a wide range of other authenticators. And doesn't have the same loss of vault issues with using the key store that AndOTP has.

What? andOTP itself doesn't have problems with Android key store. I use it in this way and don't get any problems. Did you have any more info?

As far as I can tell, it's pretty easy to lose access to data with nearly any Android application that relies on Android's Key Store (happened to me a couple of times). I'm not sure what exact cases cause it to be wiped, but you can read more about it in a blog post I found.

You won't have these issues with AndOTP as long as you only use built-in password(and maybe PIN) mode, I believe. I would have to double check.

I'm not blaming AndOTP for Android's Key Store forgetfulness. But you can work around it, like Aegis does. Nor am I saying AndOTP is a bad 2FA application. However I do find it subpar to Aegis, for now.

Additionally, if you're worried about PGP support, you can export to an non-encrypted file for Aegis, and use Open Keychain to encrypt the plaintext vault.

If you're using AndOTP and you're happy with it, just be sure to be updated to the latest stable release. There's little reason to move. But if you do happen to want to try out Aegis, you can easily import a AndOTP vault file.

I moved because Aegis' focus on security, and the simplicity behind the project. And I believe it deserves a spot on PrivacyToolsIO.

I don't have much trust in AndOTP's developer, due to not enough knowledge about security(cryptography specifically). However the kinks have been worked out(for the most part), and things should be fine for most people. Highly recommend anyone using AndOTP to use a strong passphrase, avoid PIN mode, and Android's Key Store.

There is no PIN mode for Aegis, and you're not going to lose access to your vault as long as you remember your strong passphrase (even if you use bio-metrics for authentication, you can always unlock with the passphrase).

> > For me, I find Aegis easier to use. It supports a wide range of other authenticators. And doesn't have the same loss of vault issues with using the key store that AndOTP has. > > What? andOTP itself doesn't have problems with Android key store. I use it in this way and don't get any problems. Did you have any more info? As far as I can tell, it's pretty easy to lose access to data with nearly any Android application that relies on Android's Key Store (happened to me a couple of times). I'm not sure what exact cases cause it to be wiped, but you can read more about it in [a blog post I found](https://doridori.github.io/android-security-the-forgetful-keystore/). You won't have these issues with AndOTP as long as you only use built-in password(and maybe PIN) mode, I believe. I would have to double check. I'm not blaming AndOTP for Android's Key Store forgetfulness. But you can work around it, like Aegis does. Nor am I saying AndOTP is a bad 2FA application. However I do find it subpar to Aegis, for now. Additionally, if you're worried about PGP support, you can export to an non-encrypted file for Aegis, and use Open Keychain to encrypt the plaintext vault. If you're using AndOTP and you're happy with it, just be sure to be updated to the latest stable release. There's little reason to move. But if you do happen to want to try out Aegis, you can easily import a AndOTP vault file. I moved because Aegis' focus on security, and the simplicity behind the project. And I believe it deserves a spot on PrivacyToolsIO. I don't have much trust in AndOTP's developer, due to not enough knowledge about security(cryptography specifically). However the kinks have been worked out(for the most part), and things should be fine for most people. Highly recommend anyone using AndOTP to use a strong passphrase, avoid PIN mode, and Android's Key Store. There is no PIN mode for Aegis, and you're not going to lose access to your vault as long as you remember your strong passphrase (even if you use bio-metrics for authentication, you can always unlock with the passphrase).

John3 commented

2020-06-18 03:25:47 +00:00

(Migrated from github.com)

I have about 50, and only the auto backup works now, manually always crashes the app. And check issues on their github, I am not the only one, maybe people are facing issues with it. Maybe you should look into things before using an extreme amount of emojis and calling someone's comment 'untrue'.

😒 chill old cranky man, as I said for me never failed the export import function. If people have obscure/chinese devices/UI issues may happen 😐

I moved because Aegis' focus on security, and the simplicity behind the project. And I believe it deserves a spot on PrivacyToolsIO.

I don't have much trust in AndOTP's developer, due to not enough knowledge about security(cryptography specifically)

This ☝️

> I have about 50, and only the auto backup works now, manually always crashes the app. And check issues on their github, I am not the only one, maybe people are facing issues with it. Maybe you should look into things before using an extreme amount of emojis and calling someone's comment 'untrue'. 😒 chill old cranky man, as I said for me never failed the export import function. If people have obscure/chinese devices/UI issues may happen 😐 > I moved because Aegis' focus on security, and the simplicity behind the project. And I believe it deserves a spot on PrivacyToolsIO. > I don't have much trust in AndOTP's developer, due to not enough knowledge about security(cryptography specifically) This ☝️

beerisgood commented

2020-06-18 04:58:05 +00:00

(Migrated from github.com)

Backup system is often not working (like in the last version) that is really a pain. It feels a lot more stable and doesn't crash all the time like andOTP.

I never get a app crash in andOTP.
You also talk about security. andOTP use Android key store which is best for storing important stuff.
If Aegis doesn't do that, I wouldn't call it more secure.

> Backup system is often not working (like in the last version) that is really a pain. It feels a lot more stable and doesn't crash all the time like andOTP. I never get a app crash in andOTP. You also talk about security. andOTP use Android key store which is best for storing important stuff. If Aegis doesn't do that, I wouldn't call it more secure.

👎 1

ph00lt0 commented

2020-06-18 11:19:22 +00:00

(Migrated from github.com)

I am not using a phone of Chinese company, although all phones including yours are made there too.

😒 chill old cranky man, as I said for me never failed the export import function. If people have obscure/chinese devices/UI issues may happen 😐

You also talk about security. andOTP use Android key store which is best for storing important stuff.

I think you are mixing up users. I didn't say any of this.

I am not using a phone of Chinese company, although all phones including yours are made there too. > 😒 chill old cranky man, as I said for me never failed the export import function. If people have obscure/chinese devices/UI issues may happen 😐 > You also talk about security. andOTP use Android key store which is best for storing important stuff. I think you are mixing up users. I didn't say any of this.

alexbakker commented

2020-06-22 08:25:53 +00:00

(Migrated from github.com)

Just chiming in to say that @michaelschattgen and I are following this thread. Happy to answer questions.

You also talk about security. andOTP use Android key store which is best for storing important stuff.
If Aegis doesn't do that, I wouldn't call it more secure.

The biometric authentication of Aegis is backed by the Android Keystore. If you'd like to learn more, our own documentation and @lynn-stephenson's analysis cover how Aegis' security works.

Just chiming in to say that @michaelschattgen and I are following this thread. Happy to answer questions. > You also talk about security. andOTP use Android key store which is best for storing important stuff. If Aegis doesn't do that, I wouldn't call it more secure. The biometric authentication of Aegis is backed by the Android Keystore. If you'd like to learn more, [our own documentation](https://github.com/beemdevelopment/Aegis/blob/master/docs/vault.md) and @lynn-stephenson's [analysis](https://github.com/lynn-stephenson/analysis/blob/master/Aegis%20Authenticator%20v1.1.4.md) cover how Aegis' security works.

beerisgood commented

2020-06-22 10:55:04 +00:00

(Migrated from github.com)

The biometric authentication of Aegis is backed by the Android Keystore.

same for andOTP:

Encrypted storage with two backends:
Android KeyStore
Password / PIN

https://github.com/andOTP/andOTP/blob/master/README.md#features

> The biometric authentication of Aegis is backed by the Android Keystore. > same for andOTP: ``` Encrypted storage with two backends: Android KeyStore Password / PIN ``` https://github.com/andOTP/andOTP/blob/master/README.md#features

👎 1

alexbakker commented

2020-06-22 10:57:38 +00:00

(Migrated from github.com)

@beerisgood That's incorrect. andOTP's biometric authentication and use of the Android Keystore are completely separate.

👎 1

ph00lt0 commented

2020-06-22 11:01:26 +00:00

(Migrated from github.com)

I think Aegis is a nice open source app to store OTP codes just like andOTP. Personally I prefer Aegis. Only drawback having to add all logo's manually. I see no problem on privacy or security of the app and I think it should be listed.

beerisgood commented

2020-06-22 16:26:34 +00:00

(Migrated from github.com)

@beerisgood That's incorrect. andOTP's biometric authentication and use of the Android Keystore are completely separate.

Why did you say that? I use biometric authentication which is handled directly from Android (none fingerprint adding in andOTP needed before or possible), so it use keystore.

> @beerisgood That's incorrect. andOTP's biometric authentication and use of the Android Keystore are completely separate. Why did you say that? I use biometric authentication which is handled directly from Android (none fingerprint adding in andOTP needed before or possible), so it use keystore.

alexbakker commented

2020-06-22 17:49:21 +00:00

(Migrated from github.com)

@beerisgood The fact that you see a biometric authentication prompt does not invalidate my claim that the use of biometric authentication and the Android Keystore are completely separate in andOTP. It does have the option to encrypt with an Android Keystore key, but biometric authentication is not required for the app to be able to use that key. This is an important distinction. Additionally, modern phones can enforce biometric authentication for access to Android Keystore keys at the hardware level, rather than at the OS level, but andOTP does not make use of that feature. You can learn more about how this all works here: https://developer.android.com/training/articles/keystore#KeyUseAuthorizations.

Anyway, I think we may be getting a bit off topic here.

@beerisgood The fact that you see a biometric authentication prompt does not invalidate my claim that the use of biometric authentication and the Android Keystore are completely separate in andOTP. It does have the option to encrypt with an Android Keystore key, but biometric authentication is not required for the app to be able to use that key. This is an important distinction. Additionally, modern phones can enforce biometric authentication for access to Android Keystore keys at the hardware level, rather than at the OS level, but andOTP does not make use of that feature. You can learn more about how this all works here: https://developer.android.com/training/articles/keystore#KeyUseAuthorizations. Anyway, I think we may be getting a bit off topic here.

👍 3

thestinger commented

2020-06-22 19:52:43 +00:00

(Migrated from github.com)

As far as I can tell, it's pretty easy to lose access to data with nearly any Android application that relies on Android's Key Store (happened to me a couple of times). I'm not sure what exact cases cause it to be wiped, but you can read more about it in a blog post I found.

This is a very out-of-date post and is about legacy versions of the hardware-backed keystore on legacy devices. It's straightforward to only use the modern hardware-backed keystore and it does not have the problems that you claim.

> As far as I can tell, it's pretty easy to lose access to data with nearly any Android application that relies on Android's Key Store (happened to me a couple of times). I'm not sure what exact cases cause it to be wiped, but you can read more about it in a blog post I found. This is a very out-of-date post and is about legacy versions of the hardware-backed keystore on legacy devices. It's straightforward to only use the modern hardware-backed keystore and it does not have the problems that you claim.

❤️ 1

thestinger commented

2020-06-22 20:19:13 +00:00

(Migrated from github.com)

Using the hardware-backed keystore is not exclusive from using encryption with a passphrase. It can be used as an additional layer of security rather than as a replacement for a passphrase within the app. This app doesn't do that, but that is not an inherent limitation. The keys can be bound to the profile being unlocked too.

That old blog post was using the deprecated setEncryptionRequired API and also testing on ancient devices like Android 4.4. It has no bearing on the state of the keystore on Android 6+ devices using non-deprecated APIs. The blog post was from 2015 but it was misguided and doesn't accurately reflect the state of things 5 years ago, let alone today.

The keystore does not have the claimed issues of forgetting data. Many widely used apps use the hardware-backed keystore. The GrapheneOS Auditor project is entirely based around it including using hardware-based attestation and the StrongBox (HSM) implementation when available and has never encountered any issue like that on any device. As with anything else, implementations have bugs, but the misinformation commonly spread about it by people pushing an agenda is unfounded. The posts I see here about it are concerning. I've seen a lot of misinformation spread about these things and it has a very real negative impact on the security of the app ecosystem. I'm really curious about the motivation of spreading unfounded and uninformed claims attacking an important security feature.

Using the hardware-backed keystore is not exclusive from using encryption with a passphrase. It can be used as an additional layer of security rather than as a replacement for a passphrase within the app. This app doesn't do that, but that is not an inherent limitation. The keys can be bound to the profile being unlocked too. That old blog post was using the deprecated `setEncryptionRequired` API and also testing on ancient devices like Android 4.4. It has no bearing on the state of the keystore on Android 6+ devices using non-deprecated APIs. The blog post was from 2015 but it was misguided and doesn't accurately reflect the state of things 5 years ago, let alone today. The keystore does not have the claimed issues of forgetting data. Many widely used apps use the hardware-backed keystore. The GrapheneOS Auditor project is *entirely* based around it including using hardware-based attestation and the StrongBox (HSM) implementation when available and has never encountered any issue like that on any device. As with anything else, implementations have bugs, but the misinformation commonly spread about it by people pushing an agenda is unfounded. The posts I see here about it are concerning. I've seen a lot of misinformation spread about these things and it has a very real negative impact on the security of the app ecosystem. I'm really curious about the motivation of spreading unfounded and uninformed claims attacking an important security feature.

👍 1

lynn-stephenson commented

2020-06-22 20:30:51 +00:00

(Migrated from github.com)

In that case I stand corrected. Although I'm not sure why I've lost access to some of my AndOTP vaults on my old Kindle Fire when using Android's Key Store.

My intent isn't to spread mis-information, this has just been my experience. Thanks for your contribution.

In that case I stand corrected. Although I'm not sure why I've lost access to some of my AndOTP vaults on my old Kindle Fire when using Android's Key Store. My intent isn't to spread mis-information, this has just been my experience. Thanks for your contribution.

thestinger commented

2020-06-22 20:37:38 +00:00

(Migrated from github.com)

The hardware functionality is also incorporated into the standard disk encryption and users would lose all of their data if those components lost their state. Those claims don't have a real basis. A misguided blog post from 2015 by someone using a deprecated feature and testing on ancient releases (even at the time it was posted) from before the feature was mature is not relevant beyond avoiding that clearly deprecated features and setting a baseline like Android 6+ for not just using the hardware-backed keystore but making any security-conscious app.

The oldest supported major Android release is Android 8.0, since release branches are supported for 3 years. Devices supported for longer need to move to newer versions or they won't have security updates at all. Of course, there are also a substantial security improvements in the newer major releases. The keystore has been a solid feature since Android 6 but neither Android 6 or 7 is even maintained anymore and users on it can't have decent security for any apps, so I'm not sure how even older versions are relevant let alone Android 6 and 7 where the keystore was already robust.

Perhaps security conscious apps should be informing users if they lack security updates to the OS (including the boot / vendor patch levels) and not pretending they can provide any kind of real security on an OS without real security updates / support. Certainly don't see why they should be concerned about support for Android 4.4 or even 5. If they want to do that... okay, but it doesn't look good for them and it shouldn't be an excuse to hold back security for users on newer devices.

The hardware functionality is also incorporated into the standard disk encryption and users would lose all of their data if those components lost their state. Those claims don't have a real basis. A misguided blog post from 2015 by someone using a deprecated feature and testing on ancient releases (even at the time it was posted) from before the feature was mature is not relevant beyond avoiding that clearly deprecated features and setting a baseline like Android 6+ for not just using the hardware-backed keystore but making any security-conscious app. The oldest supported major Android release is Android 8.0, since release branches are supported for 3 years. Devices supported for longer need to move to newer versions or they won't have security updates at all. Of course, there are also a substantial security improvements in the newer major releases. The keystore has been a solid feature since Android 6 but neither Android 6 or 7 is even maintained anymore and users on it can't have decent security for any apps, so I'm not sure how *even older* versions are relevant let alone Android 6 and 7 where the keystore was already robust. Perhaps security conscious apps should be informing users if they lack security updates to the OS (including the boot / vendor patch levels) and not pretending they can provide any kind of real security on an OS without real security updates / support. Certainly don't see why they should be concerned about support for Android 4.4 or even 5. If they want to do that... okay, but it doesn't look good for them and it shouldn't be an excuse to hold back security for users on newer devices.

👍 1

blacklight447 commented

2020-10-08 08:18:21 +00:00

(Migrated from github.com)

I vote for the inclusion of Aegis, it seems well designed and is actively maintained by seemingly very competent people. The problem now is that we need to decide where to list it, should it be under the android app section, or is it better the move along and create a seperate page for Multi factor authentication methods?

👍 3

lynn-stephenson commented

2020-10-08 16:11:54 +00:00

(Migrated from github.com)

@blacklight447-ptio Is the 2FA section for hardware 2FA?

blacklight447 commented

2020-10-08 16:38:44 +00:00

(Migrated from github.com)

Well so far the hardware section is still a draft. I think the best course of action would be to create a 2fa page which explains the different means of 2fa, and have it link to the security keys portion of the hardware page. My reason for this would be that security keys often do not only support 2fa, but also some form of storage for gpg keys and the like.

subsys-R9boq8 commented

2020-10-08 17:09:54 +00:00

(Migrated from github.com)

Just asking:
Are we going to include hardware 2FA devices in the list? If so, is open-source a baseline standard anymore?
(And how do we define open-source for hardware? Hardware design including IC layout of ASICs or just IC logic like VHDL/Verilog for FPGAs?)

Just asking: Are we going to include hardware 2FA devices in the list? If so, is open-source a baseline standard anymore? (And how do we define open-source for hardware? Hardware design including IC layout of ASICs or just IC logic like VHDL/Verilog for FPGAs?)

blacklight447 commented

2020-10-08 17:17:05 +00:00

(Migrated from github.com)

I would not consider it a requirement, as to my knowledge, there is no key that's completely opensource down to the board. I see being as open as possible as a pro, but not as a requirement.

ph00lt0 commented

2020-10-08 18:20:35 +00:00

(Migrated from github.com)

@blacklight447-ptio isn't solo key open source? Nevertheless I think that this should not be a requirement indeed.

beerisgood commented

2020-10-08 18:52:05 +00:00

(Migrated from github.com)

I would not consider it a requirement, as to my knowledge, there is no key that's completely opensource down to the board. I see being as open as possible as a pro, but not as a requirement.

Nitrokey is

> I would not consider it a requirement, as to my knowledge, there is no key that's completely opensource down to the board. I see being as open as possible as a pro, but not as a requirement. Nitrokey is

blacklight447 commented

2020-10-08 19:08:12 +00:00

(Migrated from github.com)

Nope, even the normal nitro keys are closed source to some degree, only the one based on the Gnuk may be, but most others have atleast one closed source part: the smart card. Sure, its an embedded piece of burned in code that you never directly interact with anyway, but its still code nonetheless.

thestinger commented

2020-10-08 20:48:26 +00:00

(Migrated from github.com)

Trezor One and Trezor Model T have an open hardware board. Of course, the ARM SoC is proprietary, as is the case for any ARM SoC, and that's the vast majority of the complexity of hardware. They don't use a proper secure element because they didn't want to have proprietary firmware. I find it a real stretch to refer to anything like that as actually being open hardware though. They're working on a RISC-V version with an open hardware secure element but it probably won't be available for a long time.

Their primary purpose is wallet for Bitcoin / cryptocurrency but they also support SSH, GPG and U2F/FIDO2.

Trezor One and Trezor Model T have an open hardware board. Of course, the ARM SoC is proprietary, as is the case for any ARM SoC, and that's the vast majority of the complexity of hardware. They don't use a proper secure element because they didn't want to have proprietary firmware. I find it a real stretch to refer to anything like that as actually being open hardware though. They're working on a RISC-V version with an open hardware secure element but it probably won't be available for a long time. Their primary purpose is wallet for Bitcoin / cryptocurrency but they also support SSH, GPG and U2F/FIDO2.

❤️ 2

blacklight447 commented

2020-10-08 21:44:34 +00:00

(Migrated from github.com)

Well thats a bit what i was pointing to, sure, you can have an open board design, open firmware, but do far, im not aware of any security key which is truely completely open.

👍 2

freddy-m commented

2021-01-24 11:02:15 +00:00

(Migrated from github.com)

As a user of Aegis myself, I'm in favour of adding this @privacytools/editorial

👍 4

lrq3000 commented

2021-06-02 04:47:40 +00:00

(Migrated from github.com)

It should be added as a recommendation, I was desperately looking for a reliable open-source OTP manager with a cloud backup system, and I had to settle with Authy. Aegis seems perfect, it even has more organization features such a folders and a search bar. I will switch when I've got some spare time. I'm sure the recommendation will be very useful to others as well.

gary-host-laptop commented

2021-06-02 11:58:21 +00:00

(Migrated from github.com)

@lrq3000 they are currently improving the GUI a bit and planning on adding support for icons, which makes it even better.

alexbakker commented

2021-06-02 12:23:26 +00:00

(Migrated from github.com)

@LongJohn-Silver Both of those improvements have landed in the recent 2.0 release!

This repo is archived. You cannot comment on issues.