Generally speaking., if someone wants to hack your system... they will.
Now I'd argue a big problem with ONLY using a Database (SQL) is that all of the Authentication Elements essentially HAVE to be in your Application.
This is
No Bueno!
Remember, if all of the Security is done locally., then well it can easily be by-passed or recreated for anyone determined enough.
Now what you'll ideally want is a Web Host... if you have a Database then really you should also have a PHP / .NET Core Webhost.
The reason for this is because what you want to do is offload as much of the Authentication process to the Web Host as possible., with all that's being stored locally essentially a Unique User ID to let the Server know WHO is requesting access.
Ideally you'll want to Support 2FA (Google / Microsoft Authenticator)., or even write your own Mobile Authenticator App... but let's say we don't for the moment.
Well, what's another secure approach?
Honestly I'd say a "Whitelist" Approach is actually the best... typically most hack attempts aren't via Trojans, via your own Computer; but instead are Remote Attempts using acquired information.
This means we can actually have a pretty basic approach that will be quite secure.
•
What we want to do is when the account is first created a Unique Identification Code is Generated; this should be broken down into 4 - 6 Character Segments... and I'd recommend generating a 1024 / 2048bit Code.
This is NEVER sent out., so the only way for the user to get it is via writing it down / printing it out from said Account Creation.
Then when they log-in from a new Device., the Server basically asks them for 3 of the Sequences (as I said you want a big code, say 2048bit, to essentially have about a dozen 4 - 6 Character Sequences)., if it passes then that Device is "Whitelisted"
And another Unique Pass Code is sent... think of this like a "Cookie" Code., so each login a new Cookie Code is generated replacing the existing one.
Instead of typing in your password again., what we do is simply check (a) Login ID, (b) Is it on the Whitelist and (c) is the Whitelist code for THAT Device.
In this respect the password is only ever used when Authenticating a new Device., and what's more is we have crude 2-Factor just to further Authenticate; a bit like the account reset codes a lot of places now do.
Of course once Whitelisted; the password isn't used and those NOT using Whitelisted Devices with the Whitelist authentication won't be able to gain access.
Hopefully you get what I'm saying... of course I'm sure you can think of other approaches, and realistically today I'd ALWAYS suggest just using 2FA Authenticators; because these are incredibly secure (and also don't need you to verify your password) ... so again the password is rarely used / sent but rather an ever changing hardware authenticated one is (which is difficult to brute force).
