Are UID read only on mifare Classic cards? (I mean in normal cards, not UID changeable mifare cards)
I thought it was not possible but this document states that it can be changed http://arxiv.org/pdf/0803.2285.pdf :
Consequences of our attack Any system using mifare Classic cards that relies
on the secrecy or the authenticity of the information stored on sector zero is now
insecure. Our attack recovers, in a few minutes, all secret information in that sector.
It also allows us to modify any information stored there
Is that true?
UID is readable only on all MIFARE cards according the official FAQ.
Can I assign my own UID to MIFARE Cards?
UIDs for MIFARE cards are assigned during the production and it can
never be changed thereafter.
It depends on the card manufacturer. Because with Classic Mifare cards with read-only UID came also so called "magic" cards which have rewritable block 0 where is also stored card UID. To write block 0 you have to usually send "backdoor" sequence to the card, which opens block 0 for writing.
Here are examples of such cards:
http://www.proxmark.org/forum/viewtopic.php?id=6545
Related
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
I'm trying to make an app that sells a service, for which users pay based on the amount of time they've used it for, so I don't have a physical shipping address involved.
I want to be able to allow my users to save and then reference saved cards in future transactions. I know the way Stripe tracks a specific customer is through a customer_id, but I'm not sure how to attach a card to a specific customer_id and then reference it in future.
Also, I'm a little confused on the use of ephemeral_keys. Some Stripe tutorials talk about needing these on the server side, and some don't mention them at all, and that leaves me very confused.
This one talks about ephemeral_keys while creating a paymentIntent: https://stripe.com/docs/mobile/ios/basic#
And this one doesn't: https://stripe.com/docs/payments/integration-builder
Any help would be greatly appreciated! Please let me know if you need any more information from me.
PS: If you could also point me to some of the relevant View Controllers Stripe uses to save new cards and display saved cards, I'd be more than grateful!
The flow on https://stripe.com/docs/mobile/ios/basic includes the Customer for your payment context, which will cause the created PaymentMethod to be attached to that Customer. You can verify this after the initial payment by retrieving the PaymentMethod on your backend with your secret key and checking its customer field [0].
If you have a PaymentMethod and want to attach it to a Customer, you'd use the API on the backend [1].
You can retrieve a list of the Customer's existing PaymentMethods via the API [2] on the backed as well (again, with your secret key). Then you can pass a list of their id's and some identifying feature (last 4 digits, as an example) to your app in order to display and let the customer select the one they want to use. Then you take that PaymentMethod's 'id' and use it to create the new payment.
Ephemeral keys are usually only used with the iOS (or Android) SDK's, so when you're using the backend of your integration (i.e. the part that is running on a server somewhere and not distributed with your app) you generally don't need to worry about them.
[0] https://stripe.com/docs/api/payment_methods/retrieve
[1] https://stripe.com/docs/api/payment_methods/attach
[2] https://stripe.com/docs/api/payment_methods/list
I hope you are well, i am not a developer and i wanted to draw from the massive pool of expertise in here. I have an odd ish question that i can not accept the answer that i have been given as it does not add up from a security perspective.
the situation is that our API is passing a token with reference number for payment to a card payment provider which is Payment Card Industry Data Security Standard compliant, we do not want that responsibility hence we contract them. the customer enters all the details (name, card number etc etc) on the contractors site. They have a secure reporting portal that we do the reporting of daily transactions, refunds etc, so there is no need for us to have any data other than a reference number to marry it up with the token sent from us. It transpired earlier today that their API returns not only the token with the unique reference we need but the name, last 4 digits of card, address and other identifiable information, which we do not need or we want to have sight off.
The Contractor's reply was to and i quote "just ignore the data that it is return through the API and you do not need". I asked them what happens to that data a number of times and they did not provide a direct reply they just said other organisations use it that way with no issues...which as you expect have drove me absolutely bazurke.
i have found this 5 year old answer that says that disappears to the ether. I cant accept that data just disappears, insert GDPR concerns here.
What happens to unused function return values?
Apologies for the rant
TLDR: we sent token with unidentifiable personal information to card payment provider through API, Card Providers API returns name, card, address and other identifiable data. Card Providers response just ignore the information returned from the API you do not need.
thank you in advance for all your help.
So since you use a website to contact this API I will try to break down what is occurring.
You enter in a number on your website, which in turn becomes the key reference for the API call to the payment processor. The processor receives the ref number and grabs info pertaining to that number from their database. They then send this data as a response to your API call and the data is returned to the website. Now I am just speculating here but I am guessing your website does not do anything with this data, except display it. If this is the case the data is sitting in volatile memory, on the server the website is running on. Volatile memory (RAM) is memory that is not long lived, once space is needed it will be overwritten or if the system is turned off, it will be wiped immediately. Even when this data is in volatile memory it is only used in the context of your session on the website. Once you leave the page, there is no real way(easy anyway) to get that data back. It may still exist in RAM, but it is not accessible to anyone anymore and will be destroyed or overwritten once the server realizes it is not being used anymore.
There is a chance however that your website does save the API responses you get back in your own database. It sounds like this is not the case but I cannot be sure. But to ultimately answer the question, you can ignore this data and it is not very vulnerable or accessible to the outside world, so you don't have to worry about it getting into the wrong hands in this case. I hope this helps you some! Let me know if I can clarify anything for you further!
If no one uses the data, or looks at it, or stores it -- if it's just ignored -- then, yes, it disappears.
More specifically, in the computer that receives it, it's probably written into some space in volatile memory, and then the space is reused and overwritten the next time a response come in. Conceptually, at least.
It's possible that the receiving application has some kind of logs that are writing out data that is received, regardless of whether the app uses it or not, but other than that, without knowing what the app is doing, it's impossible to guess further.
Instagram, Snapchat etc. Terms of Service state that they do not allow any users under the age of 13 years, yet their platforms are flooded with young children.
My Question: In a web or mobile app for users under the age of 13 years, how can I design a verification flow that allows me to obtain "verifiable parental consent" in accordance with the US COPPA and EU GDPR laws?
I am aware that I can request the parent to provide their credit card information, which I believe will count as "verifiable parental consent". However, I am wondering if there are other options with a lower potential bounce-rate?
If this seems "too broad" a question, I am specifically looking for a verification flow that allows the parent to choose from different verification options. A flow chart would be great!
The short answer
there really isn't a good way to reliably verify someone's age without potentially alienating some segment of your user-base.
The long answer
Even your credit card solution doesn't really work for children between the ages of 13 and 18 years, where one wouldn't reasonably expect them to have credit cards or get their parents to verify age using theirs.
Some people would outright refrain from sharing other identifying documents like driver's licenses or passports out of concerns like identity-theft.
If your concerns are merely legal, then you can follow Facebook's Verification Model viz. an honor-based system coupled with a secondary mobile phone or email verification.
On the other hand, if your concerns are more towards improving user-experience, then any combination of some of the aforementioned sources of verification - Government-issued ID, Credit Cards, Phone Number, Email ID, etc. can be used depending how inclusive or exclusive you want to make your software service. You could also look to outsource this problem by relying on external authentication source(s) like Facebook Login and use the user-data collected to verify age-range.
I am doing research on an Eddystone project where the user would receive personal (and therefore to some extent confidential) information based on an Eddystone URL on their phones. There is no app involved, so the user would be directed to a webpage (based on the eddystone URL) which will display the info.
I am wondering regarding the security implications of this: Without an app, I guess the EID cannot be used - is this right (or is the EID accessible in the notification and can be passed to the destination website as a parameter)? Therefore, I suppose anyone with the name of the url could then access this information which would become a problem as you could scrap the data for every user using the service with a simple script that reads this website every now and then.
There may be a way around it if the url in the beacon can be changed on the fly to something like www.abc.com/some-random-number. That would work but it would mean that the beacon url must be updated frequently.
Does anyone know of any beacons that come with an API that would allow me to do this from a Windows machine (I know manufacturers have apps that can change beacon data but that is not an option because this should run without user intervention)? E.g. I was thinking of a USB beacon that can be accessed from a little piece of software on windows which changes the url.
Or does anyone have a better idea on how to deal with this?
Thanks,
Chris
If you are going to show the website visitors some personal and confidential information, I do think the only way to go about is to have some sort of login on the website. The ability to change randomly the URL address that the beacon broadcasts would not be helpful, as you need a way to connect the random website address to the individual accessing it. The EID is a way to distinguish which apps can receive specific beacon information - it does not check which individual is using the application. (And you can only utilize it with applications, at least for now).