I wish to encrypt small string (GPS coordinnates) then I send to a server on the Internet. I do this on Android.
I have already implemented a solution with public/private key but the result is a long string, I can't send this to the Internet because I have to work with small network quota.
Do you know if a solution exist to encrypt without increasing the size of the data ? It could be a simple algorithm (no need public/private key) but something interesting for the security.
Is there a solution ?
An encryption that preserves the message length will lack security but if that is what you want, consider using Caesar code. This is a substitution cipher in which each letter in the plaintext is replaced by a letter "some secret number" of positions down the alphabet. An attacker can easily search for that secret fixed number. Make the attacker's job harder by devising a rotating sequence of different secret numbers (that only the intended receiver knows). For ultimate security use a "one-time pad" that can be any arbitrary text known to coder and decoder, an obscure Bible verse will do. Encrypt each character of the plaintext by XOR logic combination with the corresponding character of the one-time pad. The decoder just repeats the XOR with the same character of his one-time pad.
Related
The plain text emails our company sends to clients who wish to receive them include a long string of parameters which are necessary for the business side. These are long strings including weird special characters and pipes and an email address.
The links, which are necessary for analytics and attributing sales, are therefore not fully clickable on iOS and Android, and so the parameters are not being properly logged... which potentially screws up a lot of things from analytics to attributing sales referrals.
On android devices these links fail by making the email address clickable.
On iOS devices some of the link is properly made into a clickable link., however the first part of the link is cut off at a certain number of characters, or perhaps because the string includes something that would cause it to believe it is no longer reading a hyperlink.
So:
A) Is there a character limit being applied to plaintext links in OSX, or a string combination that would cause the email to escape the text hyperlink?
B) Is there a simple way to include the email information. Some sort of escape char perhaps?
(HTML emails are the majority of what we do and we don't put a lot of effort into plaintext, because we think it drives very little sales. That is probably right... but when we're not actually tracking them it is not a scientifically sound assumption. And no doubt even a bit of bad data complicates the data analysts' jobs).
I would be interested if anybody can reference demographics on site visits from plaintext messages also... my personal guess is that if people are electing to receive emails in any kind, they are probably buying stuff. Who cares enough about data use to get plaintext emails only, but... opts into ones they don't want? In particular, because only one of the links properly tracks these users, I am guessing that their engagement is high to not be culled from the mailing lists altogether.
Since you have a logic in place, which is building your URL, you should check if your URL is correctly formed.
How to validate URL: https://stackoverflow.com/questions/1471201/how-to-validate-an-url-on-the-iphone
Once you confirm it's a valid URL, try shorten your URL using TinyUrl's API:
http://tinyurl.com/api-create.php?url=<#YOUR_URL#>
I am looking for a method to encrypt media which can only be read while a person has an "active" account eg. the media cannot be stolen... it would seem like that does not make sense if the application displaying the media can decrypt the media and display the actual photo.
Is the encryption slow?
You can achieve such functionality by using two-way encryption/decryption, based on password phrase (in binary format) and any two-way encryption algorythm, like XOR for example.
XOR encryption/decryption has linear complexity, it's extremely fast and it is hard to crack the encrypted data if you don't know what encryption algorythm has been used in first place.
The actual XOR password phrase can be associated with the user's account. As long as the account is active, the password phrase can be accessed and therefore the encrypted media can be decrypted. If the user is offline (logged out), the password phrase is inaccessible and therefore the encrypted media stays encrypted.
This can be implemented as a service - the user downloads music which can be played only while the user is logged in (i.e. has the means to access the password phrase to decrypt the music and play it).
If the key is random and is at least as long as the message, the XOR cipher is much more secure than when there is key repetition within a message.[3] When the keystream is generated by a pseudo-random number generator, the result is a stream cipher. With a key that is truly random, the result is a one-time pad, which is unbreakable even in theory.
http://en.wikipedia.org/wiki/XOR_cipher
Any crypto algorithm can be used. It should not be slower than to encrypt any file of the same size.
I just noticed this article about a mobile app that is storing user information in plaintext. I've paid attention to the idea of storing the user's password on the server (using a SHA-512 hash function), but I'm not clear on the best methods for storage of personal information at the device itself.
Let me be clear I am essentially only talking about user names and passwords. The data that my app interacts with is not at all sensitive, and I know that I can implement some sort of symmetric encryption/decryption on that data.
For user convenience purposes, I'd like to offer the user an option to store their user name and password locally so that they aren't required to enter it each time they use the app. But I know that user's tend to reuse the same password for many different purposes, which means that I need to take precautions to keep my user's passwords secure. Classic tension between convenience and security.
Is it just simply a terrible idea to ever store this information locally? Or are there relatively simple means to securely encrypt this? Do the iOS and Android O/S provide any help with this?
Not necessarily looking for exhaustive answers, but I'd really appreciate some topics to research, article links, books, etc. Thank you very much. If this is a redundant question, please direct me to any posts that give answers that are still considered current.
Thank you very much!
All data on the device is automatically encrypted by the device to some degree, using the device id as the key. This prevents data from easily being read by anything other than the device itself, or someone with the device id anyway.
There's another level of encryption that you can pile on that utilizes the passcode, called Data Protection, which prevents the data being read unless the passcode is entered.
You can manually enable data protection in your app by using NSFileManager to access files and setting the NSFileProtectionKey attribute to NSFileProtectionComplete. See: Implementing and Testing iOS data protection.
Note that the user must set their device to require a passcode, and the stronger the passcode, the more secure the data will be.
You may be able to easily enable data protection through the provisioning profile for your app, even if you don't use the NSFileManager class with NSFileProtectionComplete. See: Data Protection / NSFileProtectionComplete - successfully supported through entitlements.plist?
I still wouldn't store the password. Store a randomly generated session key that is created when they log in. At least you can expire those and it's not the plain text password.
Just a follow up to this post from a year ago. What I decided to do was to generate a random session key (similar to #Marcus Adams suggestion) but use that value as a salt. I then concatenate that session key with the user's chosen plaintext password and store this value on the device (if the user elects to store their password). i.e, the device stores this value:
device_hash = sha256(device_salt || plaintext)
That hashed value then becomes the string that I pass over HTTP to the server for validation. On the server side, I have a different salt value stored over there. When the server receives the device hash value, it has its own salt value which it concatenates to that string, and then performs its own hash. That final hash is the password that is stored in the server database. i.e., the server stores this string:
server_hash = sha256(server_salt || device_hash))
I think that this is a viable balance between security and convenience, particularly since I am only trying to protect the password, and not trying to encrypt the actual data that gets exchanged in the normal course of the app. If the user's device is compromised, no attacker can use a rainbow table or anything like that to reverse engineer the password since it is salted. SHA256 along with the long length of the password should eliminate a brute force attack if someone were truly motivated.
Curious if anyone has any criticisms of this approach.
I heard someone give a marketing pitch today regarding a framework that they are selling to prevent application piracy (which I know, you cannot). Here's the high-level overview:
Registration Process:
Phone encrypts using the server's public key: the mobile phone's IMEI number and the installed application's unique ID (assigned by the app developer) to the server i.e.,
Reg_request = Encrypt(Server_PublicKey, (IMEI||AppID))
Service decrypts Reg_request using a decryption function and its own private key to extract IMEI and AppID
Service then asks the user for payment. Upon payment, the Service generates an activation serial number based on IMEI||AppID
Service then encrypts the generated serial number with the smartphone's public key and then sends this to the user.
Upon receiving this, the application decrypts it using a decryption function and the private key stored on the smartphone to obtain the serial number.
For activation, the application passes IMEI||AppID to its own hash function to get a temporary validation serial number.
If this number matches the serial number received from the server, the activation is successful.
I have little knowledge of crypto but this looks like traditional Public-key cryptography to me. How sound is this approach or rather how difficult will it make it for the attacker to break this? And, do conventional desktop-based software use more sophisticated approaches?
The scheme you described represents nothing special, and in fact the semantics wouldn't change at all if you replaced all the public key cryptography with something like HTTPS.
My guess is that this is an instance of the classic case where managers instruct developers to add cryptography to the product to make it more secure or simply because it sounds cool, but neither of them are actually familiar with cryptography.
Asymmetric crypto has at least one advantage when it comes to license key generation. The private key can be used to encrypt license data and generate the license key while the public key is used to validate the license data. The private key will be kept private and is only used by the license generator or the license activation service. Using this method, it won't be easy to create "key generators" for anyone who is trying to tamper with your app.
In the end though, one should understand that it is extremely difficult (if not impossible) to create a scheme that can completely prevent piracy. You can only discourage end users from performing a "Casual Piracy."
This is my first question here so let me know if I'm doing things wrong!
I am building an Android application with Eclipse and am reading QR codes with the barcode reader. This is all working just fine, however, sometimes there are 'special case' barcodes that contain a 'reward' for the user.
This 'reward' is contained in a specially formatted string, this string COULD be tampered with by people who intend to cheat the system. This isn't a huge issue but I have implimented steps to prevent it, now my question is... How secure are these steps?
Here are two examples of the strings:
***Code-v1.0:31c8f90a4050:1001:0:C:1337
***Code-v1.0:6a9c4e8d92da:1002:C4D23A1B:C:1337
The strings are formatted like so:
***Code-v1.0:HASH:CODE_ID:REDEEM_ONCE:CODE_ACTION:ARG
(REDEEM_ONCE has 3 possible values)
My hashing system work like so:
salt = "************:***"; // didnt think it wise to post this, but the length is
// the same and its alphanumeric
MD5 = salt . ":" . codeParts[2] . codeParts[5] . codeParts[4] . ":" . codeParts[3] . ":";
MD5 .= codeParts[4] . codeParts[3] . ":" . codeParts[5] . codeParts[2];
Is this a secure way of doing this, the code cannot seem to be tampered without affecting the hash, but surely hashes can colide and if somebody worked out the hashing scheme it all becomes pointless (this is a little less of a risk of just 'finding' it as it's on the server side, but if somebody figures it out).
What are your thoughts?
If you sent the parts and the hash, but NOT the salt anywhere (Just to be sure ;) ), you look like you are on the right track.
Some remarks:
why are you using md5? The SHA-family is more secure.
Our payment provider recently went to formatting the strings like this, to ensure longer strings where collisions (their reasoning) are less probable:
codepart1.SALT.codepart2.SALT.codepart3.SALT etc.
Technically it wouldn't be a salt i think, but still..
So send your hash and your codeparts, and recreate the hash from the codeparts and salt/secretstring and you're set.
I see one problem: Your secretstring has to be really secret, and it's in your application. So reverse engineering could show how your hash is made, and so they can alter the fields AND the hash you are sending?