I would like to protect an NFC NTag213 tag against copying. My constraints are:
The tag must include an NDEF record with a URL readable by any NFC-compatible application.
The verification of the validity of the tag will be done via my application. It is separate from link functionality.
Basically, it should be seen as if the URL is a simple information accessible to all. And the application simply allows you to check if the tag is a copy, or an original.
The application must not store any private key or authentication information because the tag must be able to be sent to anyone, who must be able to verify that it is not a copy and open the URL.
I'm talking about NTag213 because it's well known and inexpensive, but I'm open to other tag formats. However, they must remain affordable and be compatible with inexpensive NFC devices (including smartphones).
Given the availability of changeable UID Tags and the fact that you are giving away how to validate the card, no amount of using the Unit ID, password protection or cryptographic methods is going to prevent cloning.
The UID is more like Unit ID and the NFC's design requires it only to be different when multiple Tags are presented at the same time as part of the Anti collision process.
The NFC tag with dynamic NDEF could help.
The tag keeps change the value every tap and if you know the secret key, you can verify the authenticity from the URL.
Have you seen https://youtu.be/V_sl2s9IZao
Related
I've been trying to find a way to store a piece of data relative to a customer in my store. Ideally I was hoping to be able to create a Metafield that would store a single numerical value and be retrievable by the customer's id or email.
Any thoughts or suggestions would be really appreciated. Ideally I'd like to be able to handle everything in the liquid layer by editing the html and css of the store directly. A custom app with API integration is another option but less desirable as it doesn't seem necessary and would appear to be a lot more work.
EDIT: Tried piggybacking the order (thinking orders are unique to users) but it doesn't appear that the order object is created until the checkout is complete so that isn't really useful since I want to be able to attribute the user to a session click that led them to the store.
Thanks,
Alex
You will want to use an App. First, off, that is the only way for you to alter any objects in Shopify. Secondly, you can easily store simple things like counter values on the Customer resource using metafields. Third, anything you do with metafields on the Customer would be easily visible to the customer, since you can expose those metafields using Liquid. Fourth, if you choose to use JS you must use the App Proxy pattern. Shopify will then send your JS XHR payload to your App endpoint in a secure fashion.
So your needs and how to do are not new, they are old skool in Shopify terms and very straightforward to implement.
I need to know if an installation has been paid for in the past so I can provide some premium features.
Storing a payment flag in indexeddb or the file system sounds easy to defeat. Periodically asking a server and caching the response could do the trick, but I guess the user would have to be logged-in at all times (through google or otherwise) and I'd rather not impose that restriction.
Maybe if there's a way to uniquely identify a user's machine (uuid, mac address, etc) that could allow me to determine if they've made that payment?
Ultimately, this is client side JavaScript. The only means by which you can prevent use of certain features, is to put them on your server and charge for the service.
Some weak methods for preventing access include license validation, and asking the server for non-essential information (if it was essential, then see the above).
For license validation, you could create an algorithm that takes data from the user and transforms it into something else. For example, say they create an account on your website, which your server knows is a 'pro' account. You could then take their first name and email address and do some magic on it.
Here's a simple example that takes those inputs and gives us a key. In this example if our first name is "John" and our email is "john#domain.org", then our key will be fcumnflqjpBfqockp0qtifcufLqjp. However, Tony, with the email "tony#doman.org" would recieve fcumnfvqp{Bfqockp0qtifcufVqp{
You can send this key to the user, and have your code decide whether it can extract the name and email by applying the reverse algorithm.
You can reverse the strings, do various bit math, etc. It's security by obscurity. Other than an account, this is the most common method. It's used by nearly all offline software. Its kryptonite is key generators, which reverse engineer your code, and generate keys by the algorithm you use to verify them.
All the methods such as uuid, mac address etc can be easily forged imo. I think you cannot escape keeping track of user's logged-in status. Implementing something like a cookie based mechanism would be the right way to go.
I've developed an app that allows users to upload some photos and share them on Facebook/Dropbox/Twitter etc. Recently it went live in the app store.
However, I'm having a problem now: a bot is creating accounts and uploading many photos on my server. I've temporarily disabled the app, but now I'm looking for an efficient way to prevent this bot from doing this.
The bot's ip address is changing very often so it's impossible to block the ip. He creates accounts with a very realistic name and email address so it's hard to find out which users are real and which are created by the bot.
I was thinking of using a captcha, but I'm not sure if my app will be rejected by Apple if I implement this. I'm preferably looking for a way so I can prevent him from doing his work and so I don't have to resend the app to Apple again.
Could anyone give me some advice on what I could possibly do?
Thanks!
This is how I solved a similar problem:
I implemented a token-generator, which generates a one-time token for every single data transfer with the server, so even one for login-data, sending a file etc. This token is generated by a secret algorithm and can be verified server side, since you know how you generate one.
After one token is used, put it in a temporary list for the next X minutes/hours/days (depending on how many data transfers your server can handle). When a user tries to send data with a used token (i.e. the token matches one in the "banned" list), you can be sure that someone's trying to spam you -> mark the account as "spammer" and decide what you wish to do.
The algorithm must produce a different token each time (the best way would be a one-way hash), but you have to assure specific "properties", with which you can proof its authenticity.
So one very simple example:
Your algorithm in the client is generating a number between 1000000000000000000000 and 99999999999999999999999, this number is then multiplied with 12456564 and incremented by 20349.
The server becomes a specific command and data, and the generated token. Now it checks, whether (number - 20349)%12456564 is 0. If it's 0, it was likely generated by your "secret" algorithm.
It's a very basic example but you get the idea…
I currently have an iOS app that allows people to submit content to our server (twitter like). We don't have a login system, instead we rely on the UDID of the device to uniquely identify users (yes, aware that this isn't perfect but worth the tradeoff for users not having to create an account).
Requests from the iOS app are sent as POST requests to our server and are NOT authenticated in any way.
We are currently experiencing a lot of spam (obviously) and am looking for an easy method to verify that any request hitting our server in fact came from our app - and not some script that a spammer wrote.
We have tried using the user agent string which contains the app name but that is easily spoofed. Is there any way to verify that requests hitting our server is coming from our app?
One idea might be to include a random number as a parameter, and then encrypt that number with some private key. Have the server verify that the the encrypted version is = to the plain text version. (the private key would have to be on our server as well as embedded in the app).
I'm not looking for the perfect solution - a 90% solution thats easy to implement is def preferred.
Thanks!
I'd solve this by taking the message, salting it with a secret key known only to your app, and probably adding the username and UUID, then hashing them with a SHA-1. If the hash is presented along with the data, then it will act as a digital signature, and you can be reasonably sure that the message is authentic.
The shared secret key will have to be distributed with your app, so an extremely determined attacker will be able to reverse engineer it out of your app- but a casual spammer will be far more likely to just seek greener pastures.
Another approach would be to generate a pgp private / public key pair at registration- but this is a lot of work for this problem.
I am building app that will serve some content to the users via my private server. At the server-side I would like to identify user, so that I don't serve same content twice to the same user. How can I identify user(s)?
One way is DeviceID, but user can have multiple devices...?
Is the only way to have my own user IDs for my application (registration). I don't like this as it adds extra complexity to the app.
I know it's a hard task, but maybe facial recognition (from the webcam) could help in logging in users, since it doesn't imply any relation between user and device.
For example, face.com offers a free web-based API for facial recognition.
Although, Ishu's answer (username/password) is the easiest and most standard way to do identify users.
Make an id for user's and also a login page in the app. save his id with in you content table for send that content for that user. if that content entry already having his id then don't send to him otherwise send to him.
I don't think there is another option. You must use user id nothing else.