I have a terminal that behaves this way, when offline PIN is requested and the user presses enter without typing the PIN it goes on to request online PIN instead.
I want to know if this is the recommended behaviour. My team argues that it should fail if the offline PIN is not entered instead of requesting online PIN.
This a feature called PIN bypass.
What is an additional option is subsequent PIN bypass (which means bypassing all PIN methods if bypass is requested on one of them). If you have bypass enabled but not subsequent and the next applicable method will be online PIN, it will be requested.
In either case, offline PIN is just one of the cardholder verification methods. Failing in such situation without processing the rest of the CVM List when method has 'Apply succeeding rule when this one fails' bit set would be against EMVCo specs.
Related
We created a wallet pass and sent the wallet pass invitation email to end-users. However, there was an issue with the back-end APIs which prevented the Apple pass from automatically calling the device registration API.
The question I have is, do we need to re-inform all user to reinstall the Pass, or will the Pass automatically try re-registering by calling the device API.
Thank you.
The way you have worded your question possibly describes an impossible situation. A valid pass will always attempt to register. You state that your API was the issue, but an issue with a web service implementation would not prevent devices attempting to call it.
If the pass.json contains a valid https webServiceURL an authenticationToken, it will call the device registration endpoint after it has been added to the user's wallet. If the device does not get a 201 or 200 response, it will continue to retry, progressively backing off from every few seconds, to every few days for a period of around 2 weeks.
Therefore, if your pass.json contained the correct information; assuming that the issue was with your device registration endpoint and assuming that you picked up and addressed the issue quickly, then you should see device registrations coming in without having to do anything.
If it took longer than a couple of weeks or if you want to accelerate the process, you could ask your users to toggle the Automatic Notifications setting on the back of the pass. This will force the device to attempt a re-registration.
If however, the pass does not contain a webServiceURL, or if the webServiceURL was incorrect, then the device will not call back, or will call the incorrect endpoint. In this case, the only option is to have your users reinstall the pass. In this case, it is not your API that is causing the problem, but your passes.
I would like to know if there is a possibility of changing the PIN of an EMV card using POS devices equipped with an IC Reader. Or if that functionality is reserved for ATMs only.
If its possible through POS Devices, what series of commands does one need to issue to make the PIN change.
EMV Offline PIN change is performed by issuer script that is sent together with response to authorization request. It does not matter if device is POS or ATM. It technically works the same and issuer scripts are guaranteed (up to 127 bytes) to be transferred through any authorization protocol.
ATMs have additional requirements from payment schemes, so PIN Change and PIN unblock transaction support are obligatory. With POS, there is no direct requirement to be able to initiate such transactions, but if it is performed over some other channel (IVR, online, etc), issuer scripts can transfer the PIN to the card on the next online transaction regardless if card is used on ATM or POS.
No special commands are there for PIN change, the transaction will require entering both old and new PIN, send them in encrypted PIN Blocks and the response shall contain issuer script that will be sent by EMV kernel to the card (without modification or interpretation by the device) as any other issuer script.
Side note - bigger issuer scripts are not common and handled in devices that are connected through On-us interfaces with issuer banks. For large issuer scripts, devices that can avoid card removal during the process are preferred (mostly bank owned ATMs with motorized readers).
EMV cards supported two types of pin concept -
1) Offline pin
2) Online pin.
If card supported offline pin i.e. pin is stored in the card itself and if it need to change then issuer script will be executed.
Issuer script is a set of commands that runs between POS and EMV card and change the offline pin.
If card supported online pin i.e. pin is not inside the card, saved at somewhere. For changing this pin, no need to present card at POS, can change by any mode ATM, Internet Banking etc.
Sorry my response might be late but i hope it helps. This entirely depends on the functions supported by your terminal acquire.
For offline pin change for instance;
If the function is supported by your aquirer/issuer, the user can initiate a pin change on the terminal itself.
After that, the very first transaction on the card will return an issuer script data in the tag "72" to communicate with the pin change function on the card run before the second generate Account Cryptogram. If the response to the issuer script command returns 9000, the proccess completes to second generate AC command, ortherwise the Terminal runs a trasuction reversal process hence the pin reset failed.
It is a long broad respose but i hope it covers the idea.
As long as the POS has IC reader, you can read IC card based getProcessing options and static data for authentication, the answer is YES.
Whether the PIN is stored on the card in OWNERPIN variable or at the Bank(the issuer) is a function of the card usage profile defined by the issuer. Your terminal application can communicate the PIN to the card through various processing steps.
I'm trying to completely unregister a device token using the Urban Airship API (http://docs.urbanairship.com/api/), previously registered via an iOS device. I am doing this because I would like to verify the complete remote notification registration process.
There is a GET device_id endpoint:
GET /api/device_tokens/<device_token>
I was hoping there would be an endpoint like:
DELETE /api/device_token/<device_token>
DELETE /api/device_tokens (+send json data)
Maybe what I'm looking for can be achieved some other way? Or maybe this is an incorrect flow? I believe the old interface/API had this capability which is why I assumed it still existed.
Right now I'm relying on the "last_registration" value (from the GET endpoint) to inform me that the device has been registered, but I would like some way to completely remove the registered device/token via the API.
Doesn't work that way. Apple is the one the assigns and manages the lifecycle of device tokens. Urban Airship is a provider that handles the management/storage/utilization of said device tokens. Apple, however, is the one that manages the lifecycle of the device token based on the device and its actions. The best thing is to simply listen to the feedback to determine if that device token is still active or not. Apple's documentation on the matter is available here.
In regards to the old API; there was indeed a way to mark the device as inactive. However, as stated above, Apple manages the device tokens status. So, if the DT was indeed 'active' despite a delete/inactivate call was made on that DT, Apple would simply re-activate that DT, rendering that endpoint pointless.
What is the ejabbered behavior for user who is un-expectedly disconnected from internet
vs
user who explicitly sent an 'unavailable' presence?
Would they both be considered offline (for both single user chat or MUC)?
I want a behavior where if a user is disconnected from internet, offline messages to be sent
If user sent a explicit unavailble presence, I dont want offline messages to be sent.
How can that be accomplished? I can write my hook. But I need to know in which situations, the hook will be called.
When the user gets offline, the default behaviour is the same, no matter which method is used (explicit session close or unvoluntary disconnect). This is per XMPP specification.
If you want to customise the behaviour, it will not be easy as there is no way to know the reason why a user if offline.
What I would do: I would use the last module and support an optional reason for disconnect and store it. When you disconnect unvoluntarily, I would modify code to store reason being something like "timeout". When you disconnect explicitely, I would store another flag. When you get an offline message, you can then check the reason from being offline coming from mod_last storage.
I'm building a site that offers functionality to users without requiring them to register. The idea is to send an email to the specified address containing a link with a token. That way the user would could this link anytime they want to make changes to the functionality.
While I realize that there is no way to truly secure such a concept, I'm looking for options to minimize the visibility of the token. In its current state, soon as the user clicks on the link it is added to their browser history, available to anyone who has access to the computer.
In most cases I would over come this with a simple form so that the token could be passed through with a POST request, but forms aren't really supported in emails.
So the question is, does anyone know of an alternative way to hide a token in such an email?
I'm sure you've thought of this, but you could send them a password and a link to a URL where they'd need to enter that password. If the emailed URL contained another password, it would be a smaller compromise to security than usual to make the user-entered password quite short, like a PIN number, say.
You could resend a new token every time the user wants to log in. Have them plop in their email address and send them a new token, while setting previous tokens to 'expired.' Or, if the server detects that an old link/token was used, it could automatically send a new one to the associated email address and ask the user to check their email for a new link.
That would require keeping track of old, expired tokens and the associated email addresses, but still requires no registration - just that a user check their mail every time they want to log in. You'd essentially be piggy backing on their email authentication.
It'd also be counter-intuitive for users.
This would turn the token into a cryptographic nonce, which is primarily used to prevent the replay attack you mentioned.
Another answer, perhaps more useful:
Some browsers (like Chrome) do not record 301 "Moved Permanently" redirects in the browser history. Firefox does, but there's a proposal to change that:
https://wiki.mozilla.org/Browser_History:Redirects
For example, in Chrome, if you navigate directly to
amazon.com
it will follow a 301 Redirect to
www.amazon.com
If you then check your browser history, it will only show
www.amazon.com
Thus, if your server returns a 301 redirect from the login link, the server could record the token, remove it from the redirect link, and the user's browser would only record the redirect link.
(this is my first time responding on stack overflow - let me know if my writing is unclear or if I'm missing other etiquette)