Forum Visual Studio

how to obfuscate a user/pass in C#?

LesCandleLesCandle USMember ✭✭

What's the 'correct' method to prevent someone from decompiling an IOS or Android Xamarin app to find the user/pass needed to access my database remotely?

Tagged:

Answers

  • DonFitzsimmonsDonFitzsimmons USMember ✭✭

    Ideally you wouldn't really want to persist the user's credentials on the device at all. Most apps I've work on that access a web API allow a user to enter credentials and return an authorization token. You then store the token and use it on subsequent requests.

  • LesCandleLesCandle USMember ✭✭

    The web service I've coded is extremely powerful. I'm very concerned about the possibility of having access to it hacked by decompiling the Xamarin code in combination with a single user's login/pass.

    I could have a separate web service accessed by user/pass the user would enter once and recall by 'touch id' that would provide a 'token' to be used by my main web service, but ... I'm still in the situation where someone who can get into the web service (by obtaining a valid user/pass) could really do some damage.

    Is the only solution to completely hamstring my web service so that it could only update a specific user's records as defined by the 'token', and disallow running any sql statements (just use stored procedures)?

  • DaveHuntDaveHunt USMember ✭✭✭✭✭

    Where is the hacker going to get the user's login/password? If you use https, then your communications with the server are encrypted, so that's not an issue.

    However you provide registration for the users, you should not store a password anywhere. At most, you would store an encrypted version of the password. When a user logs in, encrypt the password they entered and compare that to what's stored.

    Another possibility would be to have the registration process return a token from the web service that you then store in the keychain and use when logging into the server. That would require the user to authenticate with the keychain via passcode or touch-id to retrieve the token for passing to the service.

    Also, I wouldn't have the application making an SQL queries or calling any stored procedures. They should make requests to the web service and the web service would then run the appropriate query. That way, know information about your database is visible.

    Your main point of vulnerability is in providing the user some kind of credentials for generating the token. Whatever means you use to provide those credentials would need to be secure. One the credentials have been used once and the token generated, you should not allow that set of credentials to be used again. That should take care of everything you have control over.

  • LesCandleLesCandle USMember ✭✭

    My client is a temporary employment agency. The employee could move to another agency, and give them the user/pass.

    All calls to the datababase are from the web service.

    However, even if I use stored procedures, the primary keys tend to be rather sequential, so with obfuscated code, one could just keep sending an incrementing primary key to get data for other employees.

    Unless, I limit the stored procedure to get data for that single employee, passing it the employee's token?

    btw - have you come across any code snippets for creating 'tokens'? Are we talking about a GUID stored in the database?

    I guess I'll have to do everything with stored procedures, no sql, as that could be disasterous if hacked?

  • DaveHuntDaveHunt USMember ✭✭✭✭✭
    edited July 2016

    A GUID would work fine. Give the employee a set of unique login credentials. They log in and the server generates a GUID (or whatever), stores it somewhere on the server (a database would work), sends it back to the app, invalidates the login credentials so they can't be used again, and the app stores the token in the keychain. Whenever the app communicates with the server, it passes the token for validation.

    Obviously, you would need to invalidate the token when the employee leaves. And, yes, you should limit the user to access only data associated with their token.

    You can use SQL if you want to, just keep it in the server-side code. The app should just be making requests to the server and the server should be doing the heavy lifting.

Sign In or Register to comment.