I am using JWT for authentication. I use a signingKey to encode my token. I want to store the signingKey in a safe place on the client side (avoid hard coding it).
I was hoping to use android key store for that; but so far, I have only managed to create a key store using the JDK keytool to sign my app.
My question is: is there any way I can store a key inside the key store associated with my app, prior to its deployment on the device so that I can retrieve the key inside the app and use it to sign the JWT?
If not, what are my other options?
I developing on Xamarin. My backend is ASP .Net, deployed on Azure.
I don't know how to do it using a key store inside the App. But I have done it by storing it inside a JAR/.SO file. This gets obfuscated inside the App and is not available via reverse engineering.
Though this method solves only reverse engineering problem, the best solution would be to do with the server to avoid the network interception problem
Related
I have an app built on java, and a server built on vb.net
I'm using https to communicate between server and client
I also encrypt my post data using AES encryption
My question is how can secure my key and iv used in AES , so if someone decompile the apk he wont be able to decrypt and encrypt the data
Anyone who knows please provid an example, especially for client side
Have a look at http://truelicense.net/xref/net/truelicense/obfuscate/ObfuscatedString.html
It can hide your key from being shown as plain text when the apk file is decompiled.
But using it just adds more security layer to your app, some guys with strong reverse engineer knowledge still can figure out how to de-obsfucate your key.
I utilized the realm encryption example to make a Key and encrypt the Realm database. Then I used the Realm().writeCopyToPath(_:encryptionKey:) to make a copy to ship with my app as indicated by the documentation. I believe its my lack of knowledge in encryptions, but how does a shipped app know the encryptionKey when the user downloads the application for the first time as the key was stored in the keyChain. I assume that hardcoding the encryptionKey is a bad idea so I was wondering what the correct approach to doing this was. Thank you for your time.
It's the lack of general technical feasibility, which makes it hard to come up with a solution. When you ship encrypted prepopulated data, you have to include the encryption key as well, which means in effect that the data is not secure anymore because security by obscurity doesn't really work.
If you have some data to prepopulate, which you wouldn't consider to be sensitive, but want to store sensitive user data in your Realm, then I'd recommend loading the plain bundled data from a separate read-only Realm instance and use writeCopyToPath(_:encryptionKey:) at runtime, with a randomly generated key, you can place in the user's keychain.
While if you're afraid that e.g. your level data for your game will be stolen on a jailbroken device, where you can't count on the FairPlay encryption, bundling an encrypted Realm gives you another level of hardening for a possible "attacker". But you should make sure that you obfuscate the encryption key when you integrate it.
Depending on your use-case, you can use one of both ways or combine them both.
Beside that there is a CocoaPods plugin cocoapods-keys, which is a popular way with some great ideas how to manage encryption keys while development.
I have an app which allows connections to multiple servers. At the moment I'm storing all connection details except the password using chrome.storage.sync.
Is it possible to store username/password combinations using the standard built-in password manager ?
Is it possible to store username/password combinations using the standard built-in password manager?
In short, no. There is no API to work with password storage of Chrome.
How to do authentication in a Chrome extension anyway? Here's an old question on this topic.
What changed since then is that Chrome has now a dedicated API for OAuth, chrome.identity, which provides a secure way of logging onto web services.
However, if you're looking to make something like a local password manager, then you cannot really protect against a malicious user. All storage you can access, and all encryption/decryption functions, are available for a user to inspect.
A server component that handles a certain decryption step is a good measure, but not always applicable.
Edit: as suggested by Vloz, a Native Client module that handles crypto functions is a good step to obfuscate data.
I'm writing an iPhone app that integrates with third party APIs. These APIs use OAuth (key/secret specific to my app not per user) in order to authenticate which app the request is being made in behalf of.
Is it secure (or how secure) is it to simply put the key/secret in code? Can this sort of data be reverse-engineered? Is there a better way to go about including this data in a project?
There is no place on the iPhone to hide data. A user with a jailbroken iPhone has more control over the device than any developer. If possible you should setup a web service such as a REST or SOAP service to take care of these OAuth transactions on behalf of the client.
As Rook said earlier, there is no way to hide your data in iPhone. But you can make hacker job so difficult. I just done a work around for the same issue.
Put oAuth key information in PLIST
Mannually I encrypt this PLIST by using AES key and I got encrypted "CIPHER TEXT"
Modify the AES key by appending characters in between with your own logic. Since it required at runtime to decrypt the plist
Add this modified key with plist "CIPHER TEXT" and store this value in New plist.
Remove old plist which has oAuth information
Now you have only one plist which has encrypted value with modified KEY
Advantage:
Hacking is so difficult since hacker don't have a proper cipher text in plist
To hack this code they should know to separate Modified AES key from Cipher text.
Thou they found Modified AES key, they don't have any clue about the appending algorithm, here i simple used EVEN position of the character, but you can't modify this and you can take 3rd or 4th position of the character. Which is actually will differ for each developer
for more information please visit below link;
https://sites.google.com/site/greateindiaclub/mobil-apps/ios/securelystoringoauthkeysiniosapplication
I'd suggest looking into the Keychain services provided by Apple
http://developer.apple.com/library/ios/#documentation/Security/Conceptual/keychainServConcepts/01introduction/introduction.html
I am using a REST API that uses oauth for authentication. When registering for the service I was given my API Consumer Key and my API Shared Secret. I've been simply hardcoding the Shared Secret into my Application code and compiling it.
Is this the best way to manage a Shared Secret? That is, are there any security implications?
Should this be encrypted in some way? What are the best practices for managing this Shared Secret?
It depends a bit on where your code is running.
In your case a hacker would need to steal your dll, and read the key from the dll.
This is better than storing the key in a configuration file in plain text.
You could store the key ecrypted in a database, with the information about how to decrypt it in your dll. That way a hacker would have to both steal your dll and information from your database.