We're using the thingsboard CE for a smarthome application. We're considering the claim process to let the user to add a new device. We developed a proof of concept following the process described in here: https://thingsboard.io/docs/user-guide/claiming-devices/
Now we're considering the use case of removing the device to let another user to add it (like selling the device to another person), but when we reclaim the device (according to "Device Reclaiming API Request") the device doesn't have the secretKey, so, we cannot let another user claim the device.
Are we missing something? Is there another way to do what we want?
I'd suggest handling it in the rule chain. One solution would be to have a button on a management dashboard. Clicking the button sets a "reclaim flag" to true (or you can do it direct from default attribute edit window). The rule chain receives this action, notices the flag and does the following:
Adds a secretKey attribute
Re-enables device claiming (I think once a device is claimed it can't be reclaimed again by default)
Flips the "reclaim flag" back to false
Changes the "owner" of the device back to the tenant (optional but I recommend it).
Alternatively, if you didn't want to deal with the flag bit, you could have the rule chain listen for any time an device has it's owner changed to the tenant. Might be a little less secure though.
Related
I working on an app that is designed to be protected from unauthorized access (like, for instance, bank apps do). There are two protection options: by using biometrics (default one) and by user password. I wonder, what the best practices are to handle the situation when a user forget thier password.
I'm thinking to prompt user to enter device PIN in order to remind them the password, but I can't figure out how to do that.
I guess it really depends on exactly how sensible the information is and how you're currently storing/validating the password. But assuming your threat model is okay with a user being able to get access back just with the current device password, you could use the keychain API (not the friendliest of APIs) and store some kind of flag. When adding such item you would use SecAccessControlCreateFlag.devicePasscode which will always prompt the user for their iPhone passcode before accessing such entry. So say the user needs to reset it, if you're able to access the keychain entry, you know they entered the right device passcode and thus you should allow them to reset their app password. The main caveat would be that the user disabling their passcode or not having one would invalidate your flag so they would be locked out forever if they ever forget their app password. Of course there's a lot of additional nuance to the Keychain like whether the items get synced to other devices or not, when it's available, etc. but hopefully this is somewhat useful.
I'd like to play back credit card numbers for verification purposes; however, when you do this it exposes the redacted CC in the Request Inspector logs. Of course, I can turn these logs off, but Infosec wants more assurances that Request Inspector remains off and that we have steps in place in case it gets turned back on while live calls are arriving or is turned on and forgotten about.
Aside from seeking to have Twilio set it in a permanent state, I've proposed trying to code a status check that would account for either scenario.
That said though, is the Boolean/Toggle for Request Inspector available to be read from the API?
Example lazy code:
IF(Request inspector = 1) say "Please confirm that you wish to pay xx amount"
else if(request inspector = 0) say "Please confirm that you wish to pay x amount using your credit card 400000000000000"
Basically:
If inspector is on, don't read the CC.
If it's off, you can read CC
Twilio developer evangelist here.
In reality, you should enable PCI mode in your voice settings which is permanent.
As far as I know, you can't read or change the status of the request inspector via the API.
What I might suggest is that for testing you create a separate project within the Twilio console which is responsible for all its own resources. When you run in a test mode you can then use the credentials for this project and log or repeat actions and confirmations as you require. Then, when you run in production mode, you use your production account credentials which are in PCI mode.
I'm trying to unlock data from the keychain / secure enclave via FaceID and make it accessible for the duration of the User session (without additional unlocks).
Per the documentation for kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:
After the first unlock, the data remains accessible until the next restart. This is recommended for items that need to be accessed by background applications. Items with this attribute do not migrate to a new device.
Yet, whenever I call SecItemCopyMatching() (documentation), I'm always prompted to perform a FaceID authorization.
Can someone explain what I might be doing wrong (or misunderstanding)?
The data protection class and the access control flags assigned to a keychain item are separate.
In your question you have detailed the data protection class that you have assigned, but the behaviour you are describing is resulting from the access control flags that were specified.
The data protection class refers to the lock state of the device, not the keychain item.
If you specify one or more of these values then the specified authentication (biometric and/or passcode) is required each time the keychain item is accessed.
If you only want the user to authenticate their presence the first time the item is accessed then you could specify no access control for the item and use the local authentication framework directly. Set a flag once the user has successfully authenticated and do not prompt them again in that session (or until a certain time hasn't elapsed or whatever logic you like).
It occurs to me that to provide multi user support for an app using iCloud, a public access container could be used. From a security point of view, only my app has access to the container anyway.
I'm just wondering if this is a viable idea? Or are there implications I haven't considered / mentioned?
I was thinking I could cover the cost via a subscription. I guess I could also monitor usage and have heavy / light user subscription tiers.
This is a valid strategy. I've implemented something like this in an app by allowing the user to log in to "nearby classrooms" (accounts) that were guarded by a passcode. This requires your app client being the authority on whether or not the user can see a piece of data, though, where this is normally handled by the server.
We are building a web based system where there are money involved and we want to avoid fraud implementing a system that is able to identify the IOS device from where the requests are sent.
The reason of this security is because we offer money for execute actions from a mobile and we only want the user to obtain the money once, if we are not able to identify the device the user can execute the action several times.
This unique identifier can use any HTML, JS, server side technique, but not any native IOS call due the application is web based and it runs in a normal Safari instance.
The unique identifier is not needed to be the official UUID.
The system doesn't need to be bullet-proof just a few more difficult to cheat than a normal cookie.
The system should works in separate sessions, like if the user comes back after one week.
Heuristic based systems are welcome, also any combination of LocalStorage with Cookies, ...
The only ways you can identify a unique user/device in a web application is to use cookies and or track the user's IP address.
Of course, the IP address of a device will change as the owner moves around and cookies can be cleared/disabled or will expire after a set time.
Letting web sites access a device unique identifier such as the UDID would be a huge security risk / privacy invasion. If you were to find such a way, I would say that you found a severe security hole in iOS.
If you are only interested in triggering i.e. an email alert when an account is suspected of being stolen, you could use a heuristic based on device type (user agent string) and geo-ip-lookup to detect if the user has suddenly changed device type and continent and ask the user to confirm that this is really the case. I believe this is what e.g. Google and Facebook does.