Frequently asked questions
If you have a question we have not answered here please do email it to us: email@example.com
What happens if my device is broken?
You can always fall back to using email authentication to login. If your device gets broken, simply login from your new device using the same email address and then authenticate that new device in the same way you authenticated your original device.
What happens if my device is lost or stolen?
In this case your device could be accessed by someone other than you. Your devices should always be locked either with a pin code or biometric key such as your fingerprint or face to prevent thieves accessing any of your device’s data.
As an additional security step you can remove authorisation for the lost or stolen device inside your DID.app account (this feature is currently being developed).
What happens if I want to sell my device?
Before you sell any device you would need to remove all of your personal data including any keys used by DID.app to authenticate that device.
If you forget to remove all your data from the device when you sell it you can remove authorisation for that device inside your DID.app account at any time (this feature is currently in development).
How is account recovery via email secured?
A link containing a single use code is generated and emailed to the user. As only the owner of the email address can receive the link only they can access the account.
Where are the private keys for my device stored?
Key pairs are generated and stored by your browser.
From within the browser it is not possible to access the private key, only a reference to a private key. Private key references are stored in indexeddb, To see all the key references stored, select the storage tab in web developer tools.
Where in your computers filesystem the browser stores depends on both the browser and the operating system you are using.
For example Firefox stores data in a
storage directory located under
profile. Full details are explained here
Can DID.app be whitelabelled on my website?
The style and appearance of DID.app on your website can be customised.
Why wouldn’t I just use social logins?
DID.app is more convenient to use than social login. Users that do not have Facebook or Google accounts cannot use those social logins. If the user does have an account with Facebook or Google they still need to log into it using an email address and password.
Login method choice can cause confusion for the user. Some confusion can also occur if a user has previously signed up with Facebook but now tries to login with Google or vice versa.
There is also a security threat to consider. If a Google or Facebook account is compromised the hacker now has access to all the websites which the social login has been used to grant access.
Some users are also aware of the privacy concerns around the business models of Facebook and Google and their motivations for providing login functionality for tracking purposes.
DID.app offers a simple, secure solution that is easier to use than social logins and respects the user’s privacy.
Why does DID.app send a magic link rather than a code?
When copying a code it is possible for an attacker to mislead a user in to copying a code into the attacker’s website. This would enable the attacker to compromise the user’s account.
Requiring users to click on a link is more secure than asking them to copy a code. The link includes the correct domain and is more resistant to the kind of phishing attack described above.
What is wrong with passwords?
Passwords present many problems that cause security vulnerabilities and usability issues. Here are three of the main problems explained:
Phishing is a systemic problem. Even the best possible password is vulnerable to phishing. In 2016, 5700 passwords were stolen every minute. Unfortunately, users unknowingly hand their passwords over to hackers during phishing attacks.
Users often reuse passwords for many websites so when a phishing attack takes place many accounts are compromised at the same time.
The Human Factor
The average user has around 100 passwords, many have more. Creating and remembering these passwords is hard so the average user tends to ignore password security guidelines on aspects such as complexity and length and often uses the same password for multiple services. The result is that passwords are easily guessed by bots.
Malware on devices can record the keys pressed in order to steal a password.
For a deeper look at the issues surrounding password theft read this post by Alex Weinert at Microsoft Tech Community.
Do password managers solve the problems with passwords.
Password managers are a way to manage and remember large numbers of passwords but they fundamentally don’t solve the security issues with password theft. A user can still be tricked into handing over their password during a phishing attack. The password manager’s ‘master password’ grants access to all username and password combinations stored in the password manager and is vulnerable to the same risks as any other password. Password managers are a high-value target for hackers.
Using a password manager is a choice the user has to make and, in some cases, pay for. The website owner has no control over how well the user looks after their passwords either in a password manager or not. DID.app is different because the website owner chooses to use it to improve user experience and remove the password problem.
How does DID.app handle privacy?
Authenticating users requires them to submit an email address. Email addresses are considered personally identifiable information. DID.app stores the user’s email address in order to provide a secure authentication service.
User email addresses can be accessed by your website when using DID.app.
However, the email address is not needed to identify the user.
User identities are tied to the
sub claim in the signed ID Token, the sub value is different for each site a user visits
When using DID.app on your website you do not have to collect or store any Personally Identifiable Information (PII) to authenticate users.
DID.app can be used as part of a GDPR compliant system.