There seems to be a best practice in startups to use external services for login instead of programming this logic in-house. This has some advantages and disadvantages.
External Login – Disadvantages
You will not own you users. All the ways to identify them is hold within the 3rd party services and your app will get whatever data the user allows.
The features that the 3rd party gives are fixed. Some Identity Providers may be fast to bring new features, but this is not the case with the big ones. If you need some special kind of feature you may be better with in-house implementations.
There may be some fee after some amount of users or usage. This is OK for startups, because generally you don’t have that much users ad the beginning. But, if you succeed, you will need to migrate – if you do not have endless amount of money to invest – or already enough paying customers.
In-house Login Logic – Advantages
The Users table is the most important one. You have full control over the user’s data and the features you wish to integrate. This of course has the disadvantage that – it is hard to get it right and perfect from the start. But, while there are not so much users – it doesn’t need to be 100%.
The cap of the users you may handle is limited to the power of the server where the backend sits and the quality of your software, not on some usage limit or number of users.
Login Features
Here are some tipical feature you may integrate into a authentication system.
App Level – IP Black List
I haven’t seen from a developer side or from site user side a IP Black List implementation. But, I imagine there are such – in todays world of infinite amount of users with no knowledge who is good and who is bad. Bad behaviours could be detected with analysis of requests. If someone creates a bot – he or she may try to DDOS a Site, or try to brute force a login.
App Level IP White List
WordPress sites have this simple feature – via plugin or with configuration – of not allowing users to login – outside of very few known locations. This gives super-level security, but is only an option for very few cases – like admin user interfaces of apps. For any bigger app or corporation you will need some other solution.
Email Found
If after attmpt of login – the phone number or email is not found – it’s a simple use case.
- Someone has a typo in his email
- Someone is checking if he/she has registered before. For such cases – it is OK – to allow several failing attempts. But how much?
- Some malicious user is checking for existance of email. Partially for this case – an app level IP black list exist
If an email exists in a database – second level checks happen. This minimises the BCrypt checking target to one. Hashing with this algorithm – the outputs is different. This prevents brute-forcing checks that may happend on the sha hashing algorithm. This is especially vulnerable because of the Proof of Work improvements in software and hardware – thanks to the Crypto Blockchains.
Active Profiles
It is common for platforms to try to require human interaction in the registration or login process, before allowing profiles to do their work. Otherwise bots will swarm and invade like mad. Emails, SMSes and second pass authentactions could also be read programmatically, but still. Requiring some small step – prevents absolute beginners to automate bot interactions.
Managing Known Devices
One way of increasing security is having some kind of device identifiers from which the user is interacting – stored as part of the login/registration. This may be some newly created GUID – stored in local storage, or it may be true device identifier from the device – for mobile applications. Any attempt to login from new device should be treated with higher security requirements – before giving access.
User Level – IP White Listing
I have seen – controlled by the user – white listed IPs only in a Crypto Exchange Platform. It is common for any related to finances service to give this feature. Most people generally do not access their online accounts from a lot of places.
Second Pass Authentication
Any service that do not integrate second pass authentication is weak one. It is already a enterprise standard for banking, social media platforms, email providers and more. Authenticator apps are provided by Google, Microsoft and others. Several financially related apps have their own cusom second pass authentication and operation confirmation.
Password (and other types of security) Matches – Wrong Attempts
This is one of the obsticles of implementing custom login properly. You need to recognize every type of entry point where some confirmation happens and limit the number of attempts:
- email login with wrong password
- resetting a forgotten password
- profile activation
- sending reset email
- second pass confirmation
Reseting Stuff
Everything should be able to be reseted.
- Emails could get hacked and a user should be able to change it – via some of the second layers of identification.
- Device could get stolen and any authentication information from it should be able to be removed from the profiles
- The Internet Provider may restart their devices and the user may get new Dynamic Internet Address