Quote:
|
What I also wonder is, can I use Google Firebase for this?
|
From what I know, Firebase is aimed only for Web and Mobile, so the short answer is no. There are multiple hacky ways to use it never the less (e.g. by writing your login stuff in js, and calling it from your native app)
Surely there are other provider, which provide API's for .Not or what ever you are using, but I have no Idea about what kind of alternatives are out there, so I will briefly tell you the basics of authentification.
Basically you require a Server and a Client. The Client sends the Login data to the Server, which than can, using it's database, verify if the login is correct. Here are the first few hurdles. First, you don't want to know the users password. If you save his password in your database, any attacker who gets access to your database will have access to the passwords, and as most users use their password multiple times for different sites, this might skrew the users completely. For this issue you can use a one way function (a cryptographic secure Hash function like SHA256)
before transmitting the password. Because, if UserPW = StoredPW than SHA(UserPW) = SHA(StoredPW), without being able to recover the UserPW from the SHA sum.
The next problem arises when you have multiple accounts with common passwords. If two users have the same password they are going to have same hash (PW1 = PW2 => SHA(PW1) = SHA(PW2)). Meaning if I get your database with all the hashes, I just need to make statistical analysis of the frequency of any hashed password, and than can basically look up in a list with the most common passwords, to match the high frequent ones. Even worse, if you have password hints, and 3 people have the same Hash, but the hints H1: Famous singer H2: British celebrity H3: Rock'n'Roll, every single one of this is quite secure, but all 3 together and you know the pw is "mick jagger". This is basically why the Adobe userdata Leak was so devastating.
To tackle this you can use Salting. You basically compute rather than SHA(PW) SHA(SALT+PW) with SALT being some known but Unique(i.e. by randomness) String. You could use the Username for this so you save SHA(USERNAME + PW), which has the advantage of being able to be computed on the client side (making it more secure against eavesdropping) but has the disadvantage that an attacker could basically just bruteforce the most common passwords, as the SALT is known with the username. So common practice is to use a large random generated salt you save in your DB at the server side. If you want to be really secure you would do something linke this: Client sends SHA(USER+Pass) as LOGINDATA to server, Server Computes SHA(SALT + LOGINDATA), and checks this against it's db.
Than, let's say the user sucessfully logged in. How does the Client and Server remember this? Most commonly the server will generate a Login Token, which is send to the Client. If the Client now want's to request something from the Server, it sends the token, which the server can use to verify that you have logged in Prior. But this spawns a whole new set of problems. First, what kind of token. I kid you not, there are webapps out there that used the auto increment UserID as token. Meaning 1. If you are logged in once, you know your user ID and can never be logged out. 2. If you know your user ID (lets say it 103) than you also know the UserID of the person signed in before you (102) and so on. You basically can login as anyone you whish by just iterating over the natural numbers.
So this is a bad Idea. So you don't want to be something thats not bruteforceable, and something that can be revoked. Usually a large random number (i.e. 16 Bytes or more) is used, which is deleted on logout). But guess what, It's not that easy. First of all now your random number generation is a weak point. If you are using the standard Random function of your Programming language, It's usually something like a mersenne twister, very fast, and the numbers look quite random, but is not secure (not at all), meaning one can predict the next token -> allows steal arbitrary login tokens. Once you took care about this, what if someone get's your token? Let's say you buy a new SSD, sell your old HDD, and the buyer is able to restore your token, as you forgott to log out. He now can access the acount. You thereby should at least add some expiering mechanism for the tokens. But thats not all. What if some eavesdropper catches your token while you are using it? So you need some way of verifing the token. One way to do so is rather to check if the token is correkt, checking if SHA(IP + TOKEN) is correct, so only ones with the same IP can use this token. While this is for most cases secure enough, this completely breaks when confronted with a large NAT network, as it is deployed by smaller ISP's all around the world (as they can't afford many IP's they usually use larger NATS with hundereds of clients). Also when switching your network connection (like from mobile net to Wifi), your sockets break and you loose your IP, meaning you would have to login again (this is more a problem for mobile apps, but should not be ignored). So what to do else? MAC Address? Can be spoofed easiely. The solution is Asynchronous authentification using for example DSA (Digital Signature Algorithm). By letting the Client sign the Token with its private key, the server can ensure that the token is from the client.
Long story short, it's not easy, and usually you don't want to implement this yourself. Also I want to highlight the last part of the explaination above. For the login process being secure, you need to have some kind of signature authentification using asynchronous encryption. But if you have to do this, why use passwords at all?
Just use private key-public key authentification, i.e. via PGP. It has a lot of advantages towards usual password authentification, these are: 1. Doesn't require multiple keys to be secure, you can create one key today for all services (i.e. mail, ssh logins, etc) which will be secure for at least the next 5-10 years, while you just need to use your password once on a webpage that doesn't use hashed or salted passwords internally for your password to be broken.
2. it can't be broken by eavesdropping, as you never send your private key to anyone else
3. Even if your key get's leaked (see the HDD selling example from above) PGP provides structures to revert this key using your master key (which you should have securly stored on some external hardware (highly encrypted), burried deep in your garden, so no one will ever find it
4. There are highly secure PGP applications Open Source available, allowing you to not have to worry about security risks yourself
5. Smartcards can be used for loging in (e.g. Yubi Key), removing the risk of your key bing leaked nearly completely
6. Passwords can be weak, but even the weakest PGP key (1K) is still considered secure for the next few years (even though you should go for 4k)
Otherwise, you might want to take a look into
One Time Passwords as they will also do the trick of authentificating (like a token), but with the difference that you can detect misuse of the OTP instantly, making it more robust than a simple token
Also there are some other tricks to make it more secure. For example a challenge-response scheme, where your server sends a challenge to the client, which he needs to solve in order to continue the login process. This could either be a knowledge challenge, i.e. something only the Client can know (or compute in a short time) such that if the answer is wrong, or took to long you know it's not the real client, or some computational problem, which will take some time to compute. If the challange takes 500ms to compute, the user won't feel anything when logging in (as compared to him pressing the buttons 500ms is near nothing), but for a brute forcer this means game over, as this tenfolds the amount of time you need per login attempt.
And by far the coolest thing (which is currently a hot topic in research and not widely available) are Physical unclonable functions, which use tiny production errors in hardware to generate a footprint unique to any device which can't be spoofed, and can be used for a truely unique and secure login. But from my knowledge for them to be truely secure you would require additional hardware (that disallows unauthorized reading of these values, i.e. by measureing your energy consumption you could predict some of these functions)
