How to make a Login and Password system secure for Mobile Apps?

Asked

Viewed 1,376 times

0

I created a security system in php with mysql for my website, but through the browser on desktop computers, the session is stored in cookies, and it is easy to know which user is logged in and what its limitations in each query, since I will have administrators, and common users that can be logged into this system.

Now how can I do this in mobile apps in a secure way??

For now I’m learning and developing only by android, but I plan to create in the future on IOS and Windows Phone as well.

I created a simple active login and password on android, where it is set only as true or false, to identify when the user is logged in or not.

Now someone has some idea, what can be done, so that I can safely store who is the user who is logged in to the mobile phone, when making a query in MYSQL on my website?

Because I know that in the application to leave the user permanently logged in, and not through session as in a browser by desktop.

My fear is that any user who has root access on mobile, You can access the application database files on mobile, and can modify the information with ease. If someone has some mischief, it makes it much easier for them to try to hack an encrypted password, since they would have to have a hash stored on the device.

And also how could I know by my system which user is logged in, since I will not have how to use Sesssions in php.

Perhaps the solution is simple, but I am totally lost in this matter. Someone has done something similar, and knows a really safe way to have this communication between the app and the website, just like google apps, facebook, instagram and so on?

php android mysql ios windows-phone

  • You can use the Json Web Token - JWT for authentication.

  • Thanks @Filipemoraes, I think this will not solve my problem, because my case is very complicated. But I will try to check how this tool works and see if it is possible to adapt. Valew.

  • But if you have not checked how it works, how did you come to the conclusion that it does not solve your problem? Which part the proposed solution does not solve?

  • I logged on to the site before replying to you, and verified that it would be an encryption solution along with Find and Code, and etc. I have not yet seen fully how it works, whether it is a script that will be stored on my server, or whether it is data stored on the server of this site. And tbm has a matter of runtime, speed of information, and server overflow when you have thousands of requests in a short time. .

  • Dear friend @Filipemoraes, I think I found a very safe solution, I created an answer here explaining my idea, give a little look and see what you think: https://answall.com/a/236841/89580

2 answers

5

There are several data persistence levels in Android applications, in which you can save your authentication. One of them is SharedPreference, in which it functions as if it were a Session PHP, or even the localStorage in Javascript. Here’s how Save value using Sharedpreference and here in the documentation as How to use shared preferences.

As SharedPreferences are used in situations where there is no need to create a database, or even when there is little number of data to be stored. But as you, according to your inquiry, should know well, one should never save your passwords using these options (Session, localstorage, etc), however you can store the user’s email generate a token that can expire from time to time, generating a new token.

Read more details in the documentation on storage options.

  • So my problem is not in the storage, it is quiet for me, but in the storage mode, in the encryption and security. Pq on the desktop via Session, I leave on the server side the information about the logged-in user, such as whether he is an administrator or not, and the access codes of him, things q I could not leave on the client side. On android, if I do not leave it in client mode, I am obliged to make a query via mysql, as a new login every time the user makes an action, q in my case I believe q may overload the server.

  • So I need to know how to store data q should be on the server side, on the client side, but in a way that the client has no way to modify, nor using root access to his cell phone. A q mode does not overload the server with hundreds of queries just to verify user authenticity. ??

  • I understand what you mean, but like I said, you can generate a token and change it from time to time. If the doubt is on how to generate a token, I think the suggestion of @Filipe-Moraes would not be a bad option to solve the problem.

  • Yes, but for example, when the user logs in, I store in Ssion, the user’s code, basic data such as name, email, etc., and access codes in array, which may have 10, 20, 50 codes depending on the user. On the desktop Session is useful for each user request, no need to do a new database search, since it is all calculated on the server side. But these other methods will either force me to query the database at each request, or maybe overload the server to decrypt everything.

  • Detail q will have more than 200 thousand users. where at least 80 thousand will be able to access at the same time. I wonder if it is a good solution to have 80,000 people, doing actions at the same time where every time you do a new action, have q decrypt data, and can have hundreds of actions just for encryption in a short time for each user. I’m thinking maybe create a temporary json file already decrypted on the server side, and use the token just to know the file name, so avoid the problem of encrypting each item. Maybe it works.

  • So dude, you can do this by storing the data using Sharedpreference.

  • @Fernandovr fully agrees with you that 80thousand people making requests all the time will surely overload your system. If we are speaking the same language, the option I would join would be even Sharedpreferences to avoid overload. Otherwise, maybe I haven’t absorbed what you said. heuhuhe

  • So, but Sharedpreference, is it safe to leave decrypted data there? If the user is a hacker for example, he has root access to the phone, and decompile the application. He can’t modify everything to access the system and modify the data stored via Sharedpreference?? That’s my fear, you know? With the data stored on the guy’s phone, he’ll have a lot of time offline to try to bypass the data without the server being able to identify the attempts and block the user.

  • So kkk I think these mobile apps are bad for security when it involves important server-side data. rsrs Since I don’t know much about data security via android, I’m a little afraid to use an option, knowing that it is so easy to decompile an application and have root access.

  • I see no problem in leaving decrypted data in sharepreference, but I would understand your concern if it involves credit card numbers, bank passwords, bank accounts etc. Otherwise, name, email, name of aunt, grandfather, godson, there is no problem. ehue... Actually getting data like these first mentioned, for greater security, would be server-side storage. But for example, a person does not make a purchase every time they access the application, the request will be made once in the purchase materialization.

  • @Fernandovr but I throw you a challenge. All apps nowadays use Sharedpreferences. I challenge you to choose one of them if you want, enter as root and get the information; I give you 1 month. xD hahahaha

  • So, the problem is not the basic data, that anyone can have good access. The problems are the 10, 20, 50 access codes q are for restricted actions. If a user can know what these codes are and modify them, he may have Super User actions and thereby compromise the entire system. But I was thinking here, is there any way to get a unique code of the user’s device?? like the IMEI of the cell phone? Maybe it would be a good security if I store this data on the server side, which might solve my security problem.

  • kkkk About your challenge, I haven’t learned a lot about developing apps, I don’t know about security flaws yet, but I’ve decompiled and modified code for famous apps, and I think it’s easy for a hacker to access Sharedpreferences from an app.

  • Let’s go continue this discussion in chat.

  • It is so friend, I saw here about your challenge rsrs and managed to access the Shared preferences of all applications. And it was very easy. It sits in a file XML, inside the &#Xa folder;Root/Data/Data/Application Folder/Shared_prefs It really isn’t safe for important data. I think I’ll see a way to get a unique ID from the user’s device, or use a token just to access a file on the same server side. It’ll be the way.

  • @Fernandovr Cool. You passed the test! xD hahaha

  • You see, it does not seem but I until q am smart kkkk, I will research here the best solution and then put in response here. Even so thanks for the attention friend.

  • @Fernandovr good luck there.

  • Valeww friend, hugs. ^^

  • All right, buddy, I think I found a solution, take a look at that answer, and see what you think: https://answall.com/a/236841/89580

Show 15 more comments

0


Well, after doing a lot of research, I had an idea, but I haven’t developed it yet, but I think it might actually work.

My problem would be for a hacker to decompile the application with root access on his phone and have administrative code information that should only be on the server side. And also avoid hundreds of queries in the database each action to fetch the codes again.

The SharedPreferences would also be a bad solution to this case, since it is super easy to get caught by anyone with root access on mobile.

Using third-party Ipps would also not be a good solution, because it would depend on other servers, which would slow down my application. Then I would like a more direct solution.

So I thought maybe I could store on my server 3 types of codes, 1 unique code of the user’s mobile device that registered on my system, so I found this here that can help a lot:

Unique identifier android device

After 1 more application version code, for security that if someone decompile my application and create another one using the same source, I can change this code in the next version, making it difficult for the hacker to have to decompile everything again every update.

And 1 more token code, which changes with each action, making it difficult for the action to be used by two applications with the same user at the same time.

Logically, this does not prevent someone from stealing the login session, but at least it makes it very difficult.

On the server side I had problems with Session that every time the browser is closed it is deleted too. And with direct action from the mobile app, I had no way to keep Session active. Then I discovered that PHP has a way to rewrite the class of Session.

http://www.php.net/manual/en/function.session-set-save-handler.php

So this way I’ll rewrite a version of Ssion that will only work for mobile. On the desktop will continue Sesssion in the same original way, but I’m creating a new class, and a mobile runtime file, where every time my application goes into action it will be through this new file, having a session of its own that will always be active on the server, thus preventing the user from gaining access to administrative codes that I cannot store inside the user’s mobile phone.

I haven’t tested everything yet, but I think it’s the best solution right now.

  • I don’t think session_set_save_handler solves the problem of closing the browser, actually sessions are so close it expires, however you can control the lifespan of session cookies without needing to reimplement the whole thing, just understand the HTTP behavior and the difference in the types of cookies, it is possible to manipulate session cookies to not expire.

  • So @Guilhermenascimento, I did a new class rewriting Séssion Handler, and it worked out for me. Pq now I have all Sesssions saved in a database, and increased pro Sesssion to be deleted only if it goes 2 weeks straight without access. Even though the user closes the browser and does not use it for a while, Session is not deleted. And along with unique user device data, I create a token q checks if that Session is always being accessed from the same device and the same application. .

  • Fernando, I may be mistaken, but I believe that you just reinvented the wheel, and that you could have made a simple adjustment to cookies, but I won’t go into details, if it worked for you ok, I wish you.

  • Thank you for your opinion @Guilhermenascimento, but it was not reinventing the wheel rsrs, it would be if I did a whole job to have a same form of execution. But it was reprogramming the wheel. I changed the way the Sessions are stored in a php time folder, to be stored in the database. The q facilitates me a lot in the manipulation of it giving more resources than the basic form gave. It is even easier to monitor possible future attacks on the server. It is just one more way to have total control over the system.

  • About cookies, if you think a simple setting would solve, tell me more about how you think it could work. Perhaps knowing your way of seeing the problem, I can have new solutions. I would love to know how you would solve this case. Remembering that put cookies to be requested only by HTTP or in ssl security, are already set, and put cookies not to expire tbm has already been placed.

Browser other questions tagged php android mysql ios windows-phone

You are not signed in. Login or sign up in order to post.