I am building an app which requires a user to be uniquely identified on the server without him logging in.
I have already evaluated the App Specific Hardware ID but that seems to be dependent on the hardware config of the machine and if the user even changes a network device, it will change.
Can the EasClientDeviceInformation class along with the Id property be used for this purpose?
Thanks,
Rajeev
From the MSDN article on the EasClientDeviceInformation.Id, the Id is a:
GUID truncated from the first 16 bytes of the SHA256 hash of the MachineID, User SID, and Package Family Name where the MachineID uses the SID of the local users group.
This means that the Id should be unique for each user account and machine combination. However, I imagine a cloned OS will have the same EasClientDeviceInformation.Id. If this is not a concern for your app, then it should be enough to use by itself.
The ASHWID, if you only use the components that shouldn't change, could be another option for you. MSDN has a detailed article on how to use it.
You should definitely ignore the audio, network and Bluetooth components, as I've found they get removed if you do something as trivial as turning on airplane mode, or unplug a headset.
Related
I am building a device with GSM Modem and a SIM card. I would like to protect the SIM card with a pin to prevent its misuse when the devices are installed on field.
Storing the pin for associated SIM into each device would be cumbersome. Also, if SIM is replaced, I want the device to automatically know the PIN for the new SIM. So I was thinking of using a one way hash function to generate the pin from one or more properties of the SIM like its IMSI, ICCID, SIM Card Group Identifier, Service Provider Name etc.
When a SIM is inserted, the device can dynamically calculate the correct PIN based on these properties.
(I know that security based on secret algorithm violates the basic principles of computer security, but in this case I don't need it to be fool proof - I just need something better than leaving it unprotected.)
The problem is that none of these properties can be read before entering the PIN.
Is there any other property that can be read without entering the PIN? Or do you have any work around that does not require storing of PIN on the device in advance?
Yes, it should be possible to generate the PIN using the SIM properties itself (assuming you have relation with the card vendor and the operator).
PIN = some_function(sim_properties)
Regarding each properties that you mentioned:
ICCID - yes, this unique per card. No read restriction and cannot be updated. First choice to use.
IMSI - unique per card but cannot be used. You need to provide PIN to read this file.
SPN - yes, can be used as well, but is not unique per card. If you want to use this file, ensure that it will not be updated by operator via OTA (Over The Air) RFM (Remote File Management).
GID - this file is optional, better not to use it.
For the function itself, I propose using cryptographic hash instead only hash, to give more security.
Additionally, you may also ask the card vendor to add additional proprietary file (EF), which you can put additional data inside (additional keys, bitmasks, key index of master keys to be used, etc).
At the final step, do not forget to convert the cryptographic hash result into numeric format 4-8 digits.
Concise:
Is there a way (with YouTrack-API or somehow) to change issue ID. Say from s-5 to s-30?
Full story:
We created YouTrack project to track scientific equipment, which we produce. One device - one issue. With custom fields, we created, it is VERY convenient way to handle "device stories".
The only problem we have, is that devices have their own id numbers. If we could change issue ID so, that it corresponds to device IDs, it would be very helpful. Especially helpful, when we reference a device from other issues and other projects, and to have links with real device ids, etc.
Currently it's not possible. There's quite an old feature request on this: https://youtrack.jetbrains.com/issue/JT-11067.
How unique is MPMediaItemPropertyPersistentID? Will it even work when synching the list of IDs to another device connected to the same iTunes Account?
I want to implement a iCloud synchronized playlist solution which stores the IDs as a list and I need to know if this will be possible.
As per the documentation (emphasis mine)...
The value of the MPMediaItemPropertyPersistentID identifier persists
across application launches and across syncs that do not change the
sync status of the media item. The value is not guaranteed to
persist across a sync/unsync/sync cycle.
As such, given that it won't even persist on this basis I'd be surprised if it persisted across devices in a sufficiently robust manner, if at all.
In my understanding this is not possible. I think this ID is persistent only for each device. It is no unique identifier for a specific song in the iTunes Store. It is only a ID for your own synced songs.
As you read the documentation, you'll see how fragile this ID could be.
"The value is not guaranteed to persist across a sync/unsync/sync cycle."
So if you sync your song database with iTunes and maybe delete a song from your iOS device and the sync again and put it back to your device, you may not get the same ID again for this song. And for sure not across other devices.
So I think, what you're trying to do will not work, until you get a worldwide identical Identifier for each song of the iTunes catalogue or your own iTunes catalogue on the Mac (where the Mac has to handle the IDs).
The other answers are a little big vague, so here is an answer from my own experiences and tests:
1) You can't use MPMediaItemPropertyPersistentID to get an ID that is equal between devices.
2) The MPMediaItemPropertyPersistentID will change when the device is synced with another iTunes library or all music is removed from the device and then synced again.
The ID get's created and stored by iTunes when the song is synced on the device. If it's unsynced, the ID get's deleted.
In case somebody else lands here, like me, using a Google search:
I confirmed what middaparka said above after an iOS upgrade of my device, when my music app tried to use persistentIDs from before the upgrade. The IDs had changed, and I ended up (unwittingly) listening to many songs from my library that I don't normally listen to...
So I took middaparka's advice and constructed a persistentKey by exclusive-oring the hashes from title, artistName, albumTitle and duration. Building the persistentKey during Core Database initialization will be save time later, by avoiding multiple string comparisons when fetching items in "normal operating code."
The persistentKey strategy worked properly for songs. However, when I made a hash for albums from title, artist and releaseYear, I ended up with one collision.
I had two self-titled albums by different artists released in 1976. When the hashes for the album title and the artist were exclusive-ored, they cancelled each other out. I ended up using the hash for the duration instead of the artist, and that worked.
I may end up refining the algorithm for generating the persistentKeys later...
I have a program designed in VB.net for a wafer probing system. The software has 3 main components that come standard and three that are options. When a customer decides not to have the three options they are disabled but still in the program. If at some point they decide to buy the options, one of our technicians would have to go there and be able to access the program with an administrative account to enabled the components.
Does anyone have any suggestions on what the easiest way to accomplish this?
The absolute simplest mechanism would be to create a registry key for each component, set them to 0 by default, and have the technician change them to 1. The program would just check the registry key every time a user tries to access one of the optional parts of the application.
You could get fancier and give each customer a license key for each component, and the license keys would be stored instead of 0 or 1. If the license key validates (based on some secret property that every generated license key shares) then you let them access the optional part of the application. This has the advantage that you can keep records of who is given which key, so if your software starts getting copied around the internet, you know who shared their license key. Also it would be more difficult (not much more difficult) to unlock the optional components without paying.
The trouble is, in both cases you're at the mercy of security through obscurity and it would be rather simple to unlock the full program without paying. You have to rely on penalty clauses in your contract to scare them away from changing those values or sharing their license keys. If your customers' machines ever connect to the internet you could try submitting the values of the registry keys to a web service periodically to ensure compliance (this is evil).
Unfortunately, that's kind of the end of the story. There has really never been a successful technology-based DRM scheme that has survived scrutiny over time, even on platforms where they designed the hardware. Basically what I'm saying is, this is an unsolved problem, so don't overthink it.
Could anyone explain to me in simple programmatic terms how these RSA key dongles work? I know Blizzard has them for WoW and paypal as well as some of the trading sites.
Thanks!
The fob has a clock and a serial number that is used as a seed for a PRNG. When you hit the "show me a code" button, the fob displays a number that is the product of that timestamp and the serial number run through the PRNG. The server knows your fob's serial number and time, and does the same operation. If your codes match, you're authenticated.
You can calculate the previous/next N values on the server end to account for clock skew.
Programmatic terms aren't necessary. Just imagine two pieces of hardware (your dongle and something at the company) that generate the same numbers at the same regularly scheduled intervals. It would be virtually impossible to guess what the number is due to some proprietary algorithms, so if the number you type in (or is automatically sent by the dongle) matches the number at the server, your identity is validated.
At least with the dongle I have, you also have to supply a pin known only by you and the server. So, in order to be authenticated you need both something physical and something in your head. That combination is pretty hard to fake. Even if someone gets the dongle, unless they know your pin it's worthless. And if they know your pin, that information is worthless without the dongle.
Security Now! episode 103 talks about how they work. (That link is to the show notes, but there's a link at the top of the page to the audio podcast.)
Basically, the key fob is synchronized with a server and they're both seeded to generate the same sequence of pseudo-random numbers. The server knows it's you if you input the right number at the right time.