FEITIAN FIDO2 security keys

Posted on September 28, 2021 by workinghardinit

FEITIAN FIDO2 security keys

I requested a lab trial sample of some FEITIAN FIDO2 security keys as they offered them to interested and qualifying parties for testing purposes. I was interested in their biometric security keys. So I reached out to see if I qualified, and they sent me two securities for testing in the lab. One is the K26 BioPass FIDO2® with a USB-C interface, which has, you guessed it, biometrics, meaning fingerprints. The other one is the iePass FIDO® with both a USB-C and lightning interface. This one has no biometrics but works with touch and makes a good choice for Apple devices. Now, the focus for these security keys is most often professional use cases. Still, I also wanted to point out that you can leverage a security key for your personal online accounts.

Yes, you as an individual should also be serious about protecting your online presence. For many of us, if not most, our smartphone is the primary MFA device we use. But I am also interested in an alternative.

FEITIAN

FEITIAN has a wide range of FIDO2 security keys for the many different needs and budgets out there. For me, biometrics is a must for the best possible security. However, they also offer other models, including versatile FEITIAN FIDO2 security keys that offer multiple interfaces like USB, NFC, and Bluetooth. That makes them more widely employable, but as said, I am focusing my efforts on biometric capable ones.

When it comes to biometrics, FEITIAN is the first to offer me that capability. Hence they caught my interest. In addition, ad far as I know, FEITIAN was the first vendor to achieve the FIDO Biometric Component Certification on April 29, 2021. That is a requirement to qualify for FIDO Level 3 and higher Certification. Next to that, they are very responsive to my communications and feedback. So far, so good! I know of one other vendor that has biometric FIDO2 keys available, that’s TrustKey. I know Yubikey has had them coming but so far they are not available.

Why a FIDO2 security key?

I usually use a smartphone as my primary MFA tool. A smartphone offers push notification MFA challenges that are easy to approve, allows TOTP code to access services, and can receive single-use passcodes via SMS or e-mail. On top of that, a good smartphone is fingerprint protected. That is a lot of flexibility on a single device most of us carry around daily anyway.

Redundancy for your smartphone

You can use a second smartphone for redundancy, but I use a FIDO2 security dongle where possible. I hang it on my key chain, and even when I merely forgot my phone that day, I have the security keys as a second option handy. That is far more likely to work than counting on having that second phone in my pocket.

So why use a FIDO2 security key? Well, firstly, when using MFA, and most certainly when going ultimately passwordless, you need a second way of accessing your account. I don’t just mean your emergency recovery key or such, but a backup device to answer your MFA challenges. I do this just in case you forget or lose or damage your smartphone or FIDO2 security key and can’t wait for all that to be fixed, replaced, and otherwise handled.

FIDO2 keys as primary and backup MFA solution

Secondly, sometimes FIDO2 security keys are the primary choice, depending on the variety of organizations’ needs, processes, and approaches to dealing with MFA.

Biometrics

I prefer security keys with biometrics. Together with their PIN code, the registered fingerprints provide a device that remains very secure, even when lost. It is also still secure when you leave the security key on your device. Merely touching it is not enough. The fingerprint needs to match even when your device or service does not prompt for your PIN. That keeps your kids or colleagues out of your accounts when you are not around. Secondly, you can register the fingerprints of another person you trust. That comes in handy if access is needed and you are incapacitated. A use case for this is for break glass accounts to Azure, for example.

Where to use FIDO2 security keys?

People use FIDO2 security keys most often to secure applications, services in professional settings (Azure AD, O365, websites of various professional services, etc.). That said, I use them for my personal security needs as well where ever I can. They are my second MFA device next to my smartphone. I like them, and I promote them to friends and family as I explain to them about MFA and the passwordless future. Yes, I do that. It is a requirement. That requirement materializes as mandatory security training when they dare ask me to help them select a new laptop or computer.

So in a few upcoming blog posts, I will discuss how to set them up and use them with various personal and professional services. Think about Microsoft’s Outlook, Teams, OneDrive, and services like Twitter, my WordPress blog, and my personally hosted IAAS VM for RDP or console access.

Figure 2: That’s me logging in to Twitter with my FEITIAN BioPass security key.

You can also use them with your client device or on a server with the right MFA provider or security vendors software and protect access when services like Windows Hello are not available to you for whatever reason.

I have found the FEITIAN FIDO2 security keys easy to use and to work reliably. In addition, they appear to be of high quality and solid enough to survive on my keychain.

Mind you, you cannot use a FIDO2 security key everywhere yet, which I find a pity. It shows security still has some work to do. But, where I can use a FIDO2 security key in combination with a smartphone authenticator app.

No matter what, use MFA wherever you can

Remember that with MFA, you are far less likely to become a victim of unauthorized access to your clients and services. It makes so much sense it should be the default for everyone today. It is an essential step on the road to an actual passwordless world in a zero-trust environment. We are getting closer to that world as recently, Microsoft allows you to remove the password from your personal Microsoft account when you have MFA in place.

Disclaimer

FEITIAN did not sponsor me or otherwise reward me for writing this blog post. However, they did provide me with the two FIDO2 security keys, which I appreciate as it helps me test and show scenarios in the lab and at presentations. For that, I would like to thank them.

SecretStore local vault extension

Posted on May 17, 2021 by workinghardinit

What is the SecretStore local vault extension

The SecretStore local vault extension is a PowerShell module extension vault for Microsoft.PowerShell.SecretManagement. It is a secure storage solution that stores secret data on the local machine. It is based on .NET cryptography APIs, and works on Windows, Linux, macOS thanks to PowerShell Core.

The secret data is stored at rest in encrypted form on the file system and decrypted when returned to a user request. The store file data integrity is verified using a cryptographic hash embedded in the file.

The store can be configured to require a password or operate password-less. Requiring a password adds to defense-in-depth since password-less operation relies solely on file system protections. Password-less operation still encrypts data, but the encryption key is stored on file and is accessible. Another configuration option is the password timeout, which by default is 15 minutes for automation purposes you can use Unlock-SecretStore to enter the password for the current PowerShell session for the duration of the timeout period.

Testing the SecretStore local vault extension

Below you will find a demonstration script where I register a vault of the type secret store. This is a local vault extension that creates its data and configuration files in the currently logged-in user scope. You specify the vault type to register by the ModuleName parameter.

$MySecureVault1 = 'LocalSecVault1'
#Register Vault1 in secret store
Register-SecretVault -ModuleName Microsoft.PowerShell.SecretStore -Name 
$MySecureVault1 -DefaultVault

#Verify the vault is there
Get-SecretVault

#Add secrets to Vault 1
Set-Secret -Name "DATAWISETECH\serverautomation1in$MySecureVault1" -Secret "pwdserverautom1" -Vault $MySecureVault1
Set-Secret -Name "DATAWISETECH\serverautomation2in$MySecureVault1" -Secret "pwdserverautom2" -Vault $MySecureVault1
Set-Secret -Name "DATAWISETECH\serverautomation3in$MySecureVault1" -Secret "pwdserverautom3" -Vault $MySecureVault1

#Verify secrets
Get-SecretInfo

Via Get-SecetInfo I can see the three secrets I added to the vault LocalSecVault1

SecretStore local vault extensionThe three secrets I added to vault LocalSecVault1

The configuration and data are stored in separate files. The file location depends on the operating system. For Windows this is %LOCALAPPDATA%\Microsoft\PowerShell\secretmanagement\localstore. For Linux and MacOS it is $HOME/.secretmanagement/localstore/

As you can see this happens under the user context. Support for all users or machine-wide context or scope is a planned future capability, but this is not available yet.
Access to the SecretStore files is via NTFS file permissions (Windows) or access control lists (Linux) limiting access to the specific user/owner.

Multiple Secret stores

It is possible in SecretManagement to register an extension vault multiple times. The reason for this is that an extension vault may support different contexts via the registration VaultParameters.

At first, it might seem that this means we can create multiple SecretStores but that is not the case. The SecretStore vault currently operates under the scope of the currently logged-on user at a very specific path. As a result, it confused me when I initially tried to create multiple SecretStores. I could see all the secrets of the other stores. Initially, that is what I thought happend. Consequenlty, I had a little security scare.. In reality, I just register different vault names to the same SecretStore as there is only one.

$MySecurevault2 = 'LocalSecVault2'
$MySecureVault3 = 'LocalSecVault3'

#Register two more vaults to secret store
Register-SecretVault -ModuleName Microsoft.PowerShell.SecretStore -Name $MySecurevault2 -DefaultVault
Register-SecretVault -ModuleName Microsoft.PowerShell.SecretStore -Name $MySecureVault3 -DefaultVault

#Note that all vaults contain the secrets of Vault1
Get-SecretInfo
 
#Add secrets to Vault 2
Set-Secret -Name "DATAWISETECH\serverautomation1in$MySecureVault2" -Secret "pwdserverautom1" -Vault $MySecureVault2
Set-Secret -Name "DATAWISETECH\serverautomation2in$MySecureVault2" -Secret "pwdserverautom2" -Vault $MySecureVault2
Set-Secret -Name "DATAWISETECH\serverautomation3in$MySecureVault2" -Secret "pwdserverautom3" -Vault $MySecureVault2

#Note that all vaults contain the secrets of Vault1 AND Vault 2
Get-SecretInfo

Now, if you think, that multiple SecretStores per user scope are a good idea there is an open request to support this: Request: Multiple instances of SecretStore · Issue #58 · PowerShell/SecretStore (github.com).

KeePass SecretManagement extension vault

Posted on May 12, 2021 by workinghardinit

KeePass SecretManagement extension vault

The SecretManagement and SecretStore can work with SecretManagement extension vault modules. These can be found in the PowerShell Gallery using the “SecretManagement” search tag. Some example are:

I use KeePass and as such, the KeePass SecretManagement extension vault is the one I will demonstrate. First of all, install the module. Note that I chose to use the most recent beta version, which is 0.9.2-beta0008 at the time of writing this blog post.

Install-Module -Name SecretManagement.KeePass -AllowPrerelease

Naturally, if you haven’t installed SecretManagement and SecretStore modules yet, you must now really do that to be able to play with them.

Install-Module Microsoft.PowerShell.SecretManagement, Microsoft.PowerShell.SecretStore

Now that has been taken care of we can start testing the KeePass SecretManagement extension vault.

Using the KeePass SecretManagement extension vault

I created a demo KeePass .kdbx file in which I stored some example user names with their passwords. This file has a master password. You can also use a key or the Windows user account if you want to do so.

Now I will register the KeePass file as a Vault

Register-KeePassSecretVault -Name 'WorkingHardInITKeePassVault' -Path 'C:\SysAdmin\Authentication\workinghardinit.kdbx' -UseMasterPassword

KeePass SecretManagement extension vaultRegister the KeePass Vault

As you can see this prompts you for the KeePass Master Pasword.

Keepass Master Password
Enter the Keepass Master password for: C:\SysAdmin\Authentication\workinghardinit.kdbx
Password for user Keepass Master Password:

Now that is done, I will unlock the KeePass secret vault so I can use it in automation without being prompted for it. By default, it remains unlocked for 900 seconds (15 minutes). This is configurable.

Unlock-KeePassSecretVault -Name 'WorkingHardInITKeePassVault'

Unlock the KeePass Vault, by entering the store password and, if not opened yes the KeePass master password

$FCcreds = Get-Secret -Name 'FC Switch 01'  -Vault 'WorkingHardInITKeePassVault'
$FCSwitchUser = $FCcreds.GetNetworkCredential().UserName
$FCSwitchPwd  =$FCcreds.GetNetworkCredential().Password
write-Host -foregroundcolor Green "FC Swicth 01 username $FCSwitchUser has $FCSwitchPwd for its password"

KeePass SecretManagement extension vault — We grab the username for the FC Switch 01 entry in the KeePass secret Vault.

Note that the entry for the secret is a network credential. As result, we can use the properties of the credential object to obtain the username and password in plain text. That is to say, we can (and should) use the credentials directly. You do not need to show or use the password in plain text. I did this here to show you that we got the correct values back.

Updating and adding secrets

Currently, updating the secrets with is not supported.

Let’s hope that theu allow updating and document using the hash table to enter metadata better in the future.

We need to first remove the existing one for now and re-enter the information. We’ll see how this evolves

Remove-Secret -Name 'FC Switch 01' -Vault 'WorkingHardInITKeePassVault'
$FCcreds = Get-Credential -UserName 'fcadmin'
Set-Secret -Name 'FC Switch 01' -Secret $FCcreds -Vault 'WorkingHardInITKeePassVault'

Finally, the good news is that there is also a PowerShell KeePass module that you can use for that sort of work. So you have the means in PowerShell to do so. See Getting Started · PSKeePass/PoShKeePass Wiki (github.com).

Conclusion

That was fun, was it not? The SecretManagement and SecretStore modules are going places. I hope this helps and happy scripting!

Protecting your Veeam Backup and Replication Server is critical

Posted on April 15, 2020 by workinghardinit

Introduction

In this blog, we will demonstrate one of the things that can go wrong when someone gets a hold of your Veeam Backup & Replication server administrative credentials. They can do more than “just” delete all your backups, replicas, etc. When they can logon to the Veeam Backup & Replication Server itself they can also grab all the credentials form the Veeam configuration database. Those credentials normally have privileges that you do not want to fall into the wrong hands. These are quite literally the keys to the kingdom. Hence, protecting your Veeam Backup & Replication Server is critical.

Protecting your Veeam Backup & Replication Server is critical

Security is not about one feature, technology or action. It takes a more holistic approach. It requires physical security to start with. You also need to adhere to the principles of least privilege rigorously. All this while locking down access, reducing the attack surface, leveraging segmentation, etc.

A key element lies in prevention. You must avoid the harvesting of those credentials. For this reason, you absolutely must practice privileged credential hygiene. Today you also want to leverage multi-factor authentication in order to protect access even better. All this, and more, prevents unauthorized access in the first place. Even when one measure fails. Read Veeam Backup & Replication 9.5 Update 3 — Infrastructure Hardening for more details on this.

Protecting your Veeam Backup & Replication Server is critical — Add MFA to portect your credentials being abused when compromised

Veeam Backup & Replication itself requires credentials to do its work of protecting data and workloads. Access to servers, proxies, repositories, interaction with virtual machines, etc. cannot happen without such credentials. Veeam encrypts the passwords of these users via strong encryption. They use the Microsoft CryptoAPI (FIPS certified) with the machine-specific encryption key for this.

As a side note, you might have seen the big fuss around the critical vulnerability in January 2020 regarding CryptoAPI. This is a reminder of why you need to keep your systems patched.

It ensures decryption of those passwords on another host than the one were encrypting them happened, fails. This means that even if someone steals the configuration database, or in some shape, way or form gets a hold of the encrypted password in the database they cannot be decrypted. This is an industry-standard and quite safe. What you need to know is that when someone gains access to your machine with local administrative rights, all bets are off.

What can happen?

The moment an attacker logs on to the Veeam Backup & Replication server with administrative rights, it is game over.

They will be able to grant themselves access to SQL Server and query it for the credentials. With that information, all they need to do is load and use a Veeam DLL to decrypt them. When this runs on the server where you encrypted them, this will succeed. If anyone would get hold of the encrypted password and tries to decrypt them on another host this will fail as that host has the wrong machine-specific key.

Let me emphasize once more that this is not a insecure implementation by Veeam. When you store encrypted passwords for a service, that service must be able to decrypt them. Otherwise, they can never use them. You cannot get the passwords via the GUI or the Veeam PowerShell commands. But via code, this is quite possible.

Sample code to proof that protecting your Veeam Backup & Replication Server is critical

I assembled a little PowerShell script that grabs the data from the Veeam configuration database. For this purpose, I filter out the passwords that have an empty string. We loop through the ones that remain and decrypt the passwords. In the end, I decided not to post the script as it might help people with bad intentions. I know it won’t stop bad actors cold in their tracks and maybe I will update this post later. But for now, did not include it.

Sorry, right now you can only see the output below from a example VBR Server

In the screenshot below you can see the results. This is a demo lab with demo credentials, so no worries about showing this to you. Remember that you can only decrypt the password on the Veeam Backup & Replication server where you encrypted them.

To prove a point we will grab the encrypted passwords and try to decrypt them on another VBR server so we have around to do so. This fails with an Exception calling “GetLocalString” with “1” argument(s): “Key not valid for use in specified state. error.
“

As you can see even if you get a hold of the encrypted strings they cannot be decrypted on another machine. You must do this on the machine that encrypted them.

Conclusion

While to some this might be a shock when they first learn of this., it is not a gaping security hole. It just shows you that security is more than encryption. It takes multiple measures on multiple levels to protect assets. I repeat, protecting your Veeam Backup & Replication Server is critical. For many people, this is indeed an eye-opener. The lesson is that you must protect your assets adequately. Do not bank on one feature to hold off any and all threats by itself. That is asking for the impossible.

I do hope that all Veeam software itself will also support MFA in the future. That would also help protect access via the Veeam Backup & Replication console.

Working Hard In IT

My view on IT from the trenches

Category Archives: Security

FEITIAN FIDO2 security keys