Passkeys Demo

In this demo, we will be creating a new account using just our email. Using a platform authenticator, like Apple Passkeys or Windows Hello will make this pretty easy. They are integrated in the operating system and synced across devices. I will be using macOS with the integrated Passwords app, but this is supported in Windows through Windows Hello, or you could store, sync and use Passkeys using a Google Chrome Profile.

As you can see, there is no intermediate step. No need to use a separate app to store your passwords securely. A Passkey will be generated and stored in the authenticator in one simple step. This Passkey will be automatically synced across devices and available on my iPhone.

Opening the Password application, I already can confirm my new Passkey has been stored for “localhost”. Notice the user name is also there, meaning you won’t need to fill it during the login process.

The username isn’t important or even required, it’s just to display a friendly name for this user. A Passkey will include the user ID, which can be any arbitrary String you want. In my example, I’ve used the new Random.UUID method, but this is completely up to you. And this is transparent for the end user.

Now, let’s try to login:

That’s it!

Another thing to notice is, while I have several Passkeys for different websites, only the relevant Passkey can be used. This makes Phishing attacks useless. End users won’t be able to use a Passkey anywhere else, just on the website where it has been created. And also, users won’t be able to send their password by mistake to an attacker because … they can’t!

For web application developers, another interesting thing to note is that you won’t be able to store a Passkey insecurely. Even if your database gets compromised, a hacker won’t be able to use the stored public keys to authenticate those users with another service. To make it easier to understand, you will be storing a lock, not the key used to open it.

Other User Journeys

My demo is just the classic email / password sign up / sign in workflow, but without using a password. Passkeys is based on WebAuthn (part of FIDO2) and there are several ways you can use this technology in your web application. For example, you could use a shared computer and still be able to securely log in using your mobile. The platform will display a QR code you can read with your phone camera, and grant the access from your personal device.

In my example application, the user can sign up using different emails. If the Passwords app encounters more than one for my domain it will allow the user to specify the Passkey to use:

Xojo will take care of preparing the WebAuthn steps, verifying signatures and doing the common busy work for you. You will have to decide which workflow makes sense for your application and perform any further verifications, like sending a verification email on register, to ensure this user owns that account.

Multi-Factor Authentication

If you already require your users to authenticate with a username (or email) and a password, you could use WebUserAuthentication as a second factor. That means the user will need to provide something this person knows (a username and password combination) in addition to something the user has (the authenticator device)

Other common multi-factor authentication schemes are email magic links and time-based one-time passwords, “TOTP”.

More factors equal better security, of course. But as usual when it comes to security, you’ll have to find the sweet spot between secure and comfortable.

Usernameless + Passwordless Authentication … Wait, What?!?

“How can I authenticate without providing my username or email?”. This is where real new possibilities arise. When you use a username with a password that only Chuck Norris and you know, this becomes a “proof of identity” (at least in theory, in practice a hacker could compromise an account using a weak password)

When using an authenticator without a username or password, it becomes a “proof of possession” of the authenticator device.

Again, think about it as a locker’s lock and a key. Everyone can see the lock, but only people with the correct key can open it. The public key would be the door’s lock, while the authenticator device would be the key. You can share the key with another person you trust to grant this person access to the contents behind that door. The difference with a real-life lock is that we will be using a really secure one, with a security key.

As long as you can proof you have a valid “key” to authenticate, you are granted to continue.

Consider the following scenario. The company could have a web application that uses a traditional username + password authentication but, for really special activities, the user needs to authenticate with a physical USB key authenticator device that is shared by everyone in the office.

Other use cases are obviously when privacy is involved. A private journal, or a private blogging service, voting. The inconvenience in this case is the user won’t be able to recover the account if they lose access to the authenticator. In this case, you might want to offer a different recovery solution, like printing a very long recovery code. If they also lose the recovery code, they will permanently lose the account.

How To Use The New Control

As you do with any other non-visual control, like a WebTimer, you can just drop the new WebUserAuthentication control into your WebPage.

Then configure its properties. The most important one is the Domain field. It must match the domain name where your application will be deployed. If you want to test it locally without using HTTPS, it must be “localhost” (“127.0.0.1” won’t work)

There are four events available:

You can use RegistrationSucceeded and AuthenticationSucceeded to interact with your Database, store the details and redirect the user to their dashboard.

In RegistrationSucceeded, a WebAuthenticationCredential will be given to you. This is a data transfer object with the following properties you need to store in your database:

• ID
• PublicKey
• AuthenticationAttempts
• DisplayName

Error will be fired when something goes wrong. A message will also show with the details about what happened, but it isn’t meant to be shared with the end user. During the sign up and sign in processes, you should display generic messages for security, to avoid letting bad actors know what’s going on. If you need to inform the user something related to these messages, you can send them an automated email instead.

CredentialRequested will be fired during the authentication ceremony. A userId and a credentialId will be given to you, and you should return a new WebAuthenticationCredential instance with the details coming from the RegistrationSucceededEvent.

Also, when AuthenticationSucceeded happens, the event will come with an authenticationAttempts parameter. This will be an incremental value used to update your credentials. This is part of the WebAuthn protocol sign in ceremony used to detect cloned authenticators, which is supported by Xojo. Please notice this value might come always as “0” when using Safari, for example, but Google Chrome will increase its value each time.

You can initiate a Registration or Authentication ceremony by calling Register or Authenticate, respectively.

• Register(userId As String, username As String = “”, displayName As String = “”)
  The parameter userId is required, the new credential will be built specifically for it. It can be anything that makes sense in your application, like an auto-incremental number or a random UUID . The other parameters are meant for giving the credential a friendly name. The username could be a nickname, or an email. In workflows where you allow the user to store more than one passkey, the displayName could be something like “Backup key”.
• Authenticate(Optional allowCredentials() As String)
  This will initiate the authentication ceremony. You can optionally pass an array of credential IDs, allowed for the user trying to get access to the protected resource.

Adoption and Compatibility

Not every user may know they even exist, what they are, how they work or if they will be more secure than using their pet’s name and birthdate. This can cause some friction. Other users that adopted the usage from day one might have at least two physical USB keys. They expect your application to allow them to enter more than one, just in case they lose their main USB key.

Passkeys are here to stay and their adoption will continue growing on web services. That said, depending on the combination of operating system and browser, there are some gotchas. Google Chrome or Firefox should work on every operating system. Apple users will probably obtain the best user experience if they’re tied to this ecosystem. Linux users using alternative browsers could experience some challenges.

If compatibility is a must for your application, you should still offer an alternative to Passkeys. For example, legacy passwords, or “magic login links” sent by email.

Wrapping Up

We are sure Passkeys will be the norm in the coming years. Read more in the Xojo Docs. Xojo is ready to embrace them and you can start adopting them in your Xojo Web application today!

Ricardo has always been curious about how things work. Growing up surrounded by computers he became interested in web technologies in the dial-up connections era. Xojo has been his secret weapon and language of preference since 2018. When he’s not online, chances are he will be scuba diving … or crocheting amigurumis. Find Ricardo on Twitter @piradoiv.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Starting with 2025r1, there’s no longer any need to delete an existing Keychain item just to update its password. All you need is a KeychainItem instance with a non-zero Handle, in other words, a properly initialized item. And the best way to get a reference to an existing KeychainItem is by using the System.Keychain.FindPassword method. For example, the following code snippet from a method with the signature FindPassword(serviceName As String) As KeychainItem:

Var itemToFind As New KeychainItem
Var password As String

// Name to find
ItemToFind.ServiceName = serviceName

// Get the password
password = System.Keychain.FindPassword(itemToFind)

Return itemToFind

Catch e As KeychainException
  Return Nil

This retrieves the password for a given Keychain item stored under the Service Name passed as the serviceName parameter. If the call to System.Keychain.FindPassword raises a KeychainException, it means there’s no password stored in the Keychain for that Service Name so we return Nil. But if the method successfully retrieves a password, it means we have a valid, properly initialized KeychainItem we can use to call UpdatePassword.

For example, create a new method with the following signature:

Public Sub CreatePassword(pass As String, label As string, serviceName As String)
  // Let's see if we have a password for the item already.
  // If that is the case, we need to update it instead of
  // creating it!
  
  Var itemToFind As KeychainItem = FindPassword(serviceName)
  
  // If we don't get a Nil KeychainItem, that means that we should
  // update the password for such KeychainItem, instead of creating a new one!
  
  If itemToFind <> Nil Then
     itemToFind.UpdatePassword(pass)
  Else
    // We got a Nil KeychainItem… what means that there is not
    // such item in the user Keychain yet, so let's create it.
    
    itemToFind = New KeychainItem
    itemToFind.Label = label
    itemToFind.ServiceName = serviceName
    System.Keychain.AddPassword(itemToFind, pass)
  End If
  
  Catch e As KeychainException
    MessageBox("Keychain error: " + e.Message)
    
End Sub

As you can see, this method takes three string parameters: the password you want to set or update, the label to use for the Keychain item (particularly useful when adding a new password for a given Service Name) and the Service Name itself, which is associated with the password.

The first thing this method does is call the FindPassword method we saw earlier. If it returns a non-nil object, we simply update the password. However, if the FindPassword method returns a nil object, we create a new KeychainItem from scratch using the provided label and serviceName parameters, then add the new password to the user’s Keychain.

Download this example project to experiment adding, deleting and/or updating passwords to your macOS Keychain.

Javier Menendez is an engineer at Xojo and has been using Xojo since 1998. He lives in Castellón, Spain and hosts regular Xojo hangouts en español. Ask Javier questions on Twitter at @XojoES or on the Xojo Forum.

• Facebook
• X
• LinkedIn
• GitHub
• YouTube

Here is the Window layout in the Xojo IDE:

I’m using a read-only TextField to display the generated password. There are a couple PushButtons for copying the password text to the clipboard and for generating a new password. I use Slider controls to set the length of the password and the number of digits and symbols to include, along with corresponding labels.

When the window opens, it populates some arrays with the acceptable characters that can be used for letters, digits and symbols. In particular, some characters are excluded such as “O”, “o”, “0” and quotes because those are difficult to distinguish. The code to do this is in the Open event:

The last line calls the GeneratePassword method which uses the settings from the user interface to generate a password. This way you’ll have a password displayed immediately when the window appears.

The GeneratePassword method first determines how many digits are needed, making sure it does not exceed the requested password length. Then it adds any symbols, also ensuring it does not exceed the set length. Lastly, if more characters are needed it adds letters to reach the desired length.

The characters are added to a String array that is then shuffled to mix all the parts together. Try commenting the Shuffle line out and when you run the project you’ll see that numbers always appear first, followed by symbols and then the letters. Here is the GeneratePassword code:

A similar technique is used by the RandomDigit, RandomLetter and RandomSymbol. It uses the Shuffle method to randomize the appropriate array and then returns the first item.

Download the Password Generator project file.

Download and check out earlier projects:

Week 1: Color Picker Desktop App

Discuss your Week 2 project in the Xojo forum:

Just Code Challenge Week 2 Projects

The best password is one that is diffcult to guess. But difficult to guess takes on a new meaning when hackers use computers to do the guessing. Hence, the best password becomes one that would take a computer so long to guess that it’s not practical to do so. That means a long series of random characters and the longer and more random, the better, and a different password for every site you use.

Make Your Passwords Strong and Long

If every password you created was different set of 100 randomly-selected characters, breaking into an account would be close to impossible for a hacker. The lower-half of the ASCII character set (the most commonly used characters) is 128 characters. The number of possible passwords for a 100 character password made from randomly-selected, lower-ASCII characters would be 100 to the 128th power. That number is so large that it would take the typical PC years to find a match. But again, the problem is that users can’t even remember a handful of meaningful passwords just 10 characters long. If the average person has 50 things in their life that each need a password, how do we get them to remember 50 unique, random 100 character passwords? We don’t.

Password manager software such as the Keychain on OS X, 1Password, or Roboform that can generate these types of passwords and store them securely on the user’s device. The long, unique and random passwords can then be entered automatically so the user doesn’t have to remember them or deal with them. How do we get people to use a password database? Easy –

We don’t allow people to choose their passwords.

Stick with me here. Imagine if websites and applications that required passwords generated the them for you rather than allowing you to choose one? Hello Mr. Perlman, your password is:

Kšs-&D“bu^–F|‹U‰Ž]qœ„“”95žžžIkKXjoš;O6u”ŒRUšd!AU€x(I”w‚‰~”Yl”F “#‚Ž‹‚:8?LD$Ž5tfK%P.VbT9HQi%Y[‰7a

You would have no choice but to use a password database to keep track of them. Now this might seem a bit extreme. However, requiring a password at all seemed extreme when we first started on the web. If websites and software applications generated the passwords at random, people would have no choice but to use a password database. It’s the login equivilent of a seatbelt law.

In this scenario, programs written by hackers to guess passwords become obsolete. Now you might say that the hackers will just turn their attention to hacking your password database. That’s true but that’s a much bigger problem for the hacker. They don’t want your credit card number. They want thousands of credit card numbers. Getting them one at a time, person by person, is totally impractical.

We’ve blogged about web security and passwords before. Well-designed websites don’t store your password, they store a hash of your password. When you attempt to login, they hash the password you type and compare it to the hash of the password in their database. If the two match, the site knows only that that they matched. The website still does not know your password, even if that website generated your password, because it shouldn’t be storing it. That’s what we do with user accounts at Xojo.

What would be required to implement such a thing?

First, websites and applications need to allow longer passwords. Passwords are usually stored in a database field so changing the field to allow a 100 character password is two seconds work. Next, you need to write the code to generate the random passwords. In Xojo, that code is a trival 5 lines. Ideally, the code creating the password could pass the password back to the user’s device securely so that it could be automatically stored in their password database without the user having to be involved.

Removing the user’s ability to choose their own password may seem draconian, but it would be the ultimate password solution. Existing password databases can be made to interact seemlessly with websites to store new passwords and pass them back when needed. Of course, websites need to be properly written to be secure and hosted in secure facilities. But the great thing about this solutions is that instead of hackers having to target 100,000 servers with valuable data on them, they have to attack potentially hundreds of millions of devices which is totally impractical.

And exactly how long would it take for a PC to crack that 100 character password I suggested above?

According to HowSecureIsMyPassword.net, it would take 69,003 NONAGINTILLION years to crack your password. I’m quite certain it’s long enough.

A website that has a login only needs to store a hash of your password after you create your account (or change your password). There is never a need to store the password itself. Hashing is one-way encryption. If a website uses a good hashing algorithm, it’s completely impractical to decrypt the hash back to the original password. When you go to login to a website, the site will take the password you just entered, hash it and compare that hash to the hash created when you created your login (or last changed your password). If they match, it knows the passwords that were used to create both hashes are the same but it still doesn’t ever need to know the password itself.

We’ve blogged before about how to securely handle passwords in app development. There are simple techniques that make it easy to disassociate the password hash from the user. That way if a hacker got your database, got all the hashes and was willing to put the enormous computing resources into decrypting a specific hash for a specific user, it still would not matter because they wouldn’t know which hash belonged to which user.

Anyone responsible for the security of a website should know all this. This is web security 101. While the identities of these websites were not made public, you can bet they were sites with a lot of users. It’s hard to believe that sites with large numbers of users wouldn’t be doing these security basics.

Though too much security is never enough, as developers, there are things we can do to keep our users’ passwords secure.

The best way to not allow passwords to be compromised is to not store the password at all. Unfortunately, I’ve seen far too many apps that have databases with a “password” column that contains the actual password! And I’m sure you’ve seen web sites that, when you click the “forgot password” link, send you an email with your actual password! This is not good. The only one who should know the password is the person who created the password.

So the first thing to do is to not store the password. Instead store a one-way hash of a password. A hash is a function that given a value, returns a new value of a fixed length that is always the same for the original value. A one-way hash is a hash that can convert text to a hash value but cannot convert the hash value back to the original text.

It just so happens that Xojo has several built-in one-way hash functions in the Crypto namespace: MD5, SHA1, SHA256, SHA512 and PBKDF2.

For example, given a password “frenchfries”, MD5 generates this hash value (converted to hex):

8D32A4B407DE20D2465467EE38DEF24C

The idea is that instead of storing the actual password, you use the hash of the password. To validate that the password is correct, when the user logs in you calculate the hash of the password they entered and then check to see if it matches the hash of the password you have stored. If they are the same then you know the password is correct even though you do not know the actual password.

This strategy is a great start, but it has a flaw: it is susceptible to a “brute-force” attack. This is where a nefarious hacker pre-calculates hash values for large amounts of common words. This is referred to as a rainbow table. Since most people choose relatively simple passwords, they will more than likely be found in a rainbow table. If a hacker gets access to your hash value and they know how it was calculated, they can then look it up in the rainbow table to see what the plain text password is.

One way to help mitigate this is to use a “salt” along with the password to create the hash. The salt is an extra value that you add to the password to generate hashes that make rainbow tables largely useless. You can use the same salt value for all the passwords or you can use something more specific for each password.

Creating an MD5 hash on the combination of the hash for “frenchfries” and the text “salted” generates this hash using MD5:

AE4D2A78B0681171F8E030C30A20F8F8

Such a value is not likely to show up in a rainbow table anywhere because it’s specific to you, thus limiting its general usefulness. A hacker would actually need to figure out how you are creating your salt value before they can generate a rainbow table.

Using a hash with a salt works well, but you also have to use a secure hashing function. It has been known for some time that MD5 and SHA1 are no longer secure hashing functions and are not recommended for use. The primary problem is that it is possible for two completely different values to generate the same hash. This flaw has been used to fake security certificates among other things. You may think it does not matter much for your purposes, but don’t be the one that is easier to hack. Use one of the other available hashing functions such as SHA256.

But even better, you can use the PBKDF2 function which is essentially a “slow” function which makes brute-force attacks more difficult to achieve. PBKDF2 with a salt and SHA256 can work really well. Here is an example:

Dim salt As Text = "salted"
Dim saltData As Xojo.Core.MemoryBlock
saltData = Xojo.Core.TextEncoding.UTF8.ConvertTextToData(salt)
Dim password As Text = "frenchfries"
Dim passwordData As Xojo.Core.MemoryBlock
passwordData = Xojo.Core.TextEncoding.UTF8.ConvertTextToData(password)
Dim hashData As Xojo.Core.MemoryBlock
hashData = Xojo.Crypto.PBKDF2(saltData, passwordData, 500, _
  32, Xojo.Crypto.HashAlgorithms.SHA256)

The resulting hash is a MemoryBlock so to display it, you’ll want to convert it to a hexadecimal value. This code can easily do that:

Private Function ConvertToHex(mb As Xojo.Core.MemoryBlock) As Text
  Dim hex As Text

  For b As Int8 = 0 To mb.Size - 1
    hex = hex + mb.UInt8Value(b).ToHex(2)
  Next

  Return hex
End Function

The hash for “frenchfries” with the salt “salted” yields this hash value using the above PBKDF2 function:

6A9C1E745EEBD7A9687DF04FC61E5C4C685537EEB4A3384531DE5687270C9DF4

Download the sample project to play around with the various hashing functions.
Updated (Sep 11, 2018) to ensure correct hex values are always displayed.
Updated (Oct 15, 2015) to ensure 2-digit hex values are used.