I need to scramble Device IDs on the Blackberry for privacy matter.
When I call the function DeviceInfo.getDeviceId() I got a 9 characters number. After convert it in Hexa, I got the real PIN number for the device (or device ID depends how you call that) on 8 characters.
Like I said, for privacy matter I can't store the PIN as is in my database. So I would like to scramble the ID to a unique one, still in 8 characters. If I do MD5 or other encryption, I always got an number containing more than 8 characters.
Do you know a way to get a unique 8 characters string from the Device ID?
Thank you.
You can use a short block cipher to obsfucate the message. Look at the CBC-MAC mode of operation.
As the output you want is actually only 4 bytes long, you could even use a CRC, such as CRC32.
Note that you would need a "perfect hash" to not have an overlap - neither short key CBC-MAC or CRC32 will give you a perfect hash. I would strongly suggest using a longer hash function.
Related
Take this hash for example:
ba7816bf 8f01cfea 414140de 5dae2223 b00361a3 96177a9c b410ff61 f20015ad
It's too long for my purposes so I intend to use a small chunk from it, such as:
ba7816bf8f01
ba7816bf
Or similar. My intended use case:
Video gallery on a website, represented by thumbnails. They are in random order.
They play in the lightbox. They don't have a unique ID, only their URL is unique.
While the lightbox is open I add something to the end of the page URL with JS History API.
//example.com/video-gallery/lightbox/ba7816bf8f01
The suffix needs to be short and simple, definitely not a URL.
People share the URL.
The server can make sense of the lightbox/ba7816bf8f01 in relation to /video-gallery.
Visiting the URL, the lightbox needs to find which video the suffix belongs to and play it.
I thought I'd SHA256 the URL of the video, use the first few characters as an ad-hoc ID. How many characters should I use from the generated hash, to considerably reduce the chance of collision?
I got the idea from URLs and Hashing by Google.
The Wikipedia page on birthday attacks has a table with the number of entries you need to produce a certain chance of collision with a certain number of bits as a random identifier. If you want to have a one in a million chance of a collision and expect to store a million documents, for example, you’ll need fewer than 64 bits (16 hex characters).
Base64 is a good way to fit more bits into the same length of string compared to hex, too, taking 1⅓ characters per byte instead of 2.
The bar code 128 subset C the number of digits should always be even.
How to print bar code with odd character? example:
1517072011170323703007607271023031701
Using DelhiXE7 and Fortes Report 4.0 VCL
Is this question related to finnish banking barcode ?
if YES: You must pad the data to be of even length, according to the documentation published by the bank. Switching the barcode encoding system is not allowed by the relevant banking standard.
reference URL: http://www.finanssiala.fi/maksujenvalitys/dokumentit/Bank_bar_code_guide.pdf
if NO: Just first encode the even-length part, then switch to code 128A or 128B using the encoding switching special "character" and finally encode the last digit using either 128A or 128B, whichever serves you better.
I'd like a regex or some function to standardize all phone number input from my ios app.
Thus inputs like the following
(212)555-5555
2125555555
212-555-5555
212 555 5555
212-5555555
all get translated to
(212) 555-5555
would this following regex work to match the phone numbers into 3 match groups which I can then format into the correct output string?
^\D?(\d{3})\D?\D?(\d{3})\D?(\d{4})$
Is the $ sign at the end of the regex required or does that mess things up?
Is regex the best way to do this in iOS?
^ and $ in a regex match the beginning and end of a line of input. You have not provided enough information to determine if these anchors are appropriate in this particular case.
Since you're working in iOS have you looked at the NSDataDetector class? It provides mechanisms for detecting strings which could be valid phone numbers in many different formats. This would give you phone number detection matching the behavior users see in many of the other apps on their devices.
NSDataDetector does not provide a mechanism for re-formatting phone numbers so you would still need to determine how you want to reformat strings detected as possible phone numbers (which may contain more or less than 10 digits). If you do so you should probably fall back to preserving the original format of any detected number which does not match one of your expected formats.
Passbook for iOS uses a serial number that your servers can use to identify a specific pass.
Does anyone know what characters are valid in the passbook serial number? I know that digits and letters are valid, but are symbols/punctuation valid as well (e.g. "-" and ".")?
Also what is the maximum length of a serial number?
Thank you.
Pretty much any character can be used, including '-' and '.', as long as the serial remains unique. Special characters, like '\' will need to be properly escaped, although these may not be compatible with your database, or may cause other problems if not handled properly elsewhere in your code.
I have just tried a pass with the following serial and it added to Passbook with no problems.
"serialNumber":"[]{}-_)(*&^%$##!`~+=|\\\/?.><,:;"
UTF8 encoded characters are also fine:
"serialNumber":"\u9127\u6a02\u611a" // Chinese characters 鄧樂愚
As for maximum length, I'm not aware of any limit, although it would be quite simple to experiment.
This serial of 400 characters also ingests ok.
"serialNumber":"0123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789"
I would recommend against using any sort of user input for the serial, since this may lead to non-unique collisions and open you up to injection attacks. Also adhering to XML standards is not a bad practice to avoid any problems if you change your architecture (say to a web service solution like AWS DynamoDB) down the line. Base64 encoding your serial would ensure widespread compatibility.
The serial can also be used to store metadata in the pass E.g.
"serialNumber":"UniqueID|data1|data2|data3|etc."
I'm looking for a RAIL way to create a very secure UID that will act as a authentication token.
I had been using UUID but was told they are not secure. I'd like to learn, what is the method of choice these days in ruby/rails 3?
This question is in no way Rails specific.
UUID is not secure for the simple fact that it is a unique identifier and it contains 'constant' parts of a given machine (e.g. it might use the MAC address for a machine), which makes it easier to guess.
If you want 100k+ strings without someone guessing one, you need to be able to distribute your keys across a large key-space. Let me explain:
If you only need 1 key (let's), you might pick 'A'. In a key-space of A-Z you have 1:26 chance of guessing it. Now, if you'd extend your key-space to A-Za-z you have a 1:52 chance of guessing.
Need more security still? Use a longer key: 'AA' 1:2704 chance.
Now, if you'd want to have 2000 keys and use a key length of 2 (e.g. 'AA'), there's a 2000:2704 => 1:1.352 chance someone might guess it. Pretty bad.
So, the key here is to pick a very long key size. With Digest::SHA1 you get 40-character keys (using Hex, with 16 different values per character). That's 1.46150164e48 unique values. Your 100k values should be random enough.
Edit:
With 40-digit HEX SHA1 values you have a 1:461501640000000000000000000000000000000000000000000 chance of guessing one. That takes ages.