Forem: bolt-io

How I verified my LinkedIn employment

bolt-io — Fri, 05 May 2023 09:28:20 +0000

The problem with LinkedIn's employment section is that you have to take it at face value. I could easily add an entry stating I have worked for Microsoft for the past 5 years and it would be up to the recruiter and/or potential employers to do their diligence to be confident in my claims. Well that's all about to change...

LinkedIn verified workplace

Microsoft and LinkedIn have released a new feature to verify a LinkedIn member's workplace using Microsoft Entra Verified ID to build confidence that the user is who they say they are and have worked where they claim they have. I won't go in to the detail here, but if you want to learn more about this feature you can do so on Microsoft's blog post.

Note: At the time of writing, this is still in private preview, and Kocho are 1 of 70 organisations testing and delivering feedback but don't worry, we will ensure this feature is refined and ready to be rolled out to the mass as soon as possible.

Steps for verification

1 - Ensure you have the latest LinkedIn mobile app:

Android 4.1.813 or newer
iOS 9.27.2336 or newer (within the app, the Apple store states 9.1.312)

2 - Open the app and navigate to your profile

3 - Open your "about this profile" section

4 - Click on "verify your workplace" - If you don't see this option, please make sure you have the correct LinkedIn app version (specified above) and that your organisation is setup for LinkedIn verified workplace.

5 - You'll be shown some information about workplace verification - click "verify" to continue

6 - Sign-in to your corporate account. This will issue you a Verified ID verified employee credential in the background

7 - Wait for your Verified ID credential to be issued - you don't need to do anything here, a webapp is issuing your verified employee credential in the background!

8 - When your credential is issued, you'll see a screen asking you to authorise the presentation of your verified employee credential to LinkedIn - Click "submit" if you're happy with the information you're sharing

9 - LinkedIn will now verify your employment, and upon success your workplace verification will be added to your profile!

And that's it! Your LinkedIn employment is verified. You can navigate to your profile and see the verification

You can also view and delete your verifications within account preferences

Conclusion

LinkedIn workplace verification is super easy to do, and it will give confidence to recruiters and employers. Once we've concluded testing with Microsoft this feature will be available to all and I encourage you to take advantage of it!

Decentralised Identity Showdown: A Comparison of did:ion and did:web

bolt-io — Mon, 27 Feb 2023 08:46:01 +0000

Preface

Decentralised identities is a new emerging identity platform based on open standards, it puts the user in control of their own data. This blog focuses on the differences of publishing your decentralised identifier (DID), used for verification of an issued credential, on web or ION. If you're new to decentralised identities, I recommend reading up on it here.

Intro

I recently setup our production Verified ID service in Azure. When you are creating a new Verified ID service, there is a choice to choose your preferred trust system. The choice is between using Web (default) or ION.

Once your Verified ID service is initialised you cannot change this trust system without deleting all your credentials and resetting the service, so it's a pretty big choice to get right... but often people are unsure about the differences of did:web and did:ion.

At a high level, did:ion and did:web are two different methods for creating and managing your decentralised identifiers. These decentralised identifiers are used to validate the authenticity of a credential being presented.

did:ion

When I setup our production service, I chose did:ion as the trust system. did:ion uses ION (Identity Overlay Network), a level 2 open and permissionless network. It can support thousands of transactions per second and uses distributed ledgers to enable censorship and be tamper evasive. It runs as a platform atop of the Bitcoin blockchain.

You can use the ION network explorer to view published documents.

did:web

On the other hand, you can chose did:web. This is a little more familiar to people as it relies on existing web technologies such as DNS and HTTPS. With this approach the trust is with the domain owner and due to needing to verify each presentation request for validity, the DID document needs to be highly available and able to respond to thousands of requests a second for large and mature implementations. If the issuer's domain is not available to verify at the time of presentation, the user may see some security warnings but can continue after accepting the warning. Will this get stricter as the platform matures... perhaps.

Decentralisation

I mentioned that did:web relies on a domain being highly available and scalable for verifying the credential being presented, by definition having reliance on this central authority is not only a single point of failure, it makes did:web less decentralised compared to did:ion. This also makes did:web less secure, as you are putting trust into the domain owner to manage and control the DID; whereas did:ion relies on a fully decentralised and distributed network overlay platform.

Conclusion

In summary, the main difference is the underlying technology. With existing web technologies like DNS and HTTPS, issuers can leverage did:web. However, for a truly decentralised platform, you should use did:ion, which uses the ION protocol and blockchain technology.

I highly recommend going for did:ion if your use case would allow it. Not only is it more secure, it's more decentralised, has a higher trust level, and ensures immutability. Moreover, did:ion will allow your issued credentials to still be issuer verified should the your implementation cease to exist in the future.

Your back-up authentication method may leave your account at risk 🔐

bolt-io — Thu, 05 Jan 2023 12:42:59 +0000

In today's world of identity and security, there is a big push for passwordless authentication. However, even when you enable passwordless, there is always the option to fallback to entering a password when using Azure Active Directory (AAD).

For those who have not randomised their AAD password when going to passwordless, there is still a risk your account can be targeted using this traditional authentication method; leaving you liable to the already established social engineering tactics.

Of course, this does not just land itself to passwords and passwordless. When I enrolled two factor authentication (2FA) with GitHub, I was given a set of recovery keys. A great initiative in order to allow users to gain access to their account should they not be able to use that mechanism anymore... but this relies on one important thing:- those security keys being stored securely. Too many people without cyber security awareness will simply copy those keys, paste them into a txt file and name that file " account recovery keys" meaning that the enhanced security on your account is just a facade should an attacker have access to your files.

Even if we are cyber conscious, there are often controls outside of our control enforced on our authentication experience. Some companies specify if you add Microsoft Authenticator as an authentication method, you must also add a second authentication method, often this is forced to be SMS/Phone based.

Your account is only as secure as your lowest authentication method rating.

What do I mean by this? Let's say you had just password authentication, this is probably bottom tier in terms of account security hygiene. Well, if you add two-factor authentication (2FA) with an SMS/Phone based one-time password (OTP), your account is undoubtably more secure than it once was but there are SMS intercept attacks that can allow attackers to have unauthorised access to your account.

Okay, so password and 2FA with SMS is insecure, so I've enrolled time-based one-time password (TOTP) to my account. Well, you're still susceptible to the SMS intercept attacks if you kept your phone authentication method on your account as a back-up authentication system; since the point of back-up authentication methods are to allow you to use that method to gain access to your account if you can't get a TOTP. Therefore, those organisations that force you to have a SMS/Phone call based back-up method are lowering your account security rating! I challenge you to take that to your security team.

My final notes on this topic:

Never use the same password across multiple accounts.
Always aim for the strongest authentication method available.
If you have recovery keys to store, make sure they are stored and secured properly.
If you enrol a stronger method then check to see if other, more susceptible, methods can be removed.
Challenge the policies in your company if you think they can improve their security posture.

How I almost got locked out of 50+ accounts

bolt-io — Tue, 04 Oct 2022 15:30:43 +0000

Background

I work with many clients and have done in my current employment since March 2020. It’s fair to say that I have access to multiple client environments; some of which I developed and provisioned, and some of which I help support. Along with my personal accounts, this means my Microsoft Authenticator app is used for 59 accounts!

I’ve also had my phone for almost 5 years. As one of the first iPhone X’s on the market, the last past year has been a struggle for keeping the available storage in check. It was time for a new phone.

New phone time

The new iPhones were out in September 2022, and I had my eyes on the iPhone 14 Pro with 1TB of storage (the other extreme, but now I know I won’t run out of storage anytime soon!).

Apple products are great for upgrading. Switched the new phone on, sat it beside the old one and it automatically prompted me to transfer all my files, apps, and settings. At the end of the transfer my old phone prompted me to reset it, so I could sell it on or give it to a family member. I decided against this, at least until I saw everything was secure, transferred, and working on the new phone.

Microsoft Authenticator

One of the things I use multiple times per day is Microsoft Authenticator. All my native AAD accounts are device enrolled and Passwordless enabled (this will become important soon).

Alongside my native accounts, I have federated accounts – these count for about 80% of the accounts I have. I can’t use my federated accounts for Passwordless sign-in, but they are used for push-notifications for multi-factor authentication (MFA) against client tenants.

I also have multiple accounts used for MFA one-time passwords (OTPs), for discord, GitHub, LinkedIn, Pluralsight, etc.

Action required

I opened my authenticator, all my Azure Active Directory (AAD) accounts, both native/local and federated had action required warning underneath them.

My new device fingerprint wasn’t the same as my old device, and I need to re-enrol my new iPhone on all of my AAD accounts.

For my native/local accounts, I could use my password to enrol the new Microsoft Authenticator app as a new trusted device… but for my native accounts I use Passwordless, therefore I did not know what my password was!

Moreover, for my federated accounts, since there is no “password handling” in the federated tenant, I could not go down the password reset route and the only option I was presented with was to scan a QR code as if I was setting up Microsoft Authenticator from scratch.

For some of my federated accounts, I had setup my phone number as an authentication method first, before enrolling the Microsoft Authenticator app. These accounts allowed me to MFA via SMS and setup the new phone, for the others… I was stuck.

Well, almost. If there is another administrator with the correct role to manage authentication methods (e.g., authentication administrator) then they could remove my old iPhone from the authentication methods.

This would force me to setup a new MFA method when signing in next time. This administrator could also add a new authentication method and setup my phone number as an authentication method to reinforce that the account remains secure.

Seems a lot of work, especially when we are talking about over 50 AAD accounts. This would take forever.

The brainwave

I didn’t wipe my old device!

There was no-one else I required bar myself if I used my old device to authenticate then transfer the authentication method over to my new device. Heading over to aka.ms/mfasetup, I successfully logged into my corporate account using Passwordless on my old device.

From this screen I was able to add a new method, my new device’s Microsoft Authenticator app.

Once I was enrolled, I could remove the old device from the list of authentication methods, just in case it fell into the wrong hands.

Success!

I was able to login with my new phone, and setup Passwordless authentication for native accounts. All I had to do now was switch organisation, use my old phone for MFA, register my new phone, delete the old, and setup a phone sign-in method (if I ever lose the device, I can use SMS as an MFA method in the future).

I then proceeded to do this for the remaining accounts, which did take a long time and was very repetitive, but this was much better than contacting each client and getting their IT support staff to reset the sign-in methods for me.

Takeaways

If you’re changing your phone, don’t wipe the existing phone until you’ve recovered all your Azure Active Directory accounts and enrolled them on the new device. The Microsoft Authenticator cloud backup and recovery steps does not mean you can instantly start using all your accounts like normal. This is due to the credential being tied to a specific device and never sent over the network; therefore, you must prove your identity and enrol the new device before the credential is created.