Have a question about beacon uuid.
If a want to avoid uuid conflict with an existing one, is there a standard or a central service to choose my uuid, and then make sure that my app will be notified with only my beacons ?
Thank you
Related
I am developing an Alexa Skill, and before releasing the first version of it, I wanted to be sure that I can notify my users about new features.
How can I do this ? What are my options ?
I saw Alexa Proactive Event, but I'm not sure about how to use it and if it's the right choice.
Following options:
Visually
(of course who reads when using alexa ;-) )
alexa developer console -> distribution -> whats new
For my skills I also updated the "detailed description" with some mini release notes before this "whats new" text field existed.
Voice
You can check in your backend logic if your user uses the skill after your update.
Therefore you would need to save the time whenever a user uses your skill (of course you need the times before your update but a backend update is independent from your skill update with certification).
Now if a requests come in you check the lastUsage time and can send out your special update message.
Of course you could also do via a flag (flag all users which got the message) instead of lastUsageTime.
Will be helpfull for persisting this data (alreadyGotUpdate message flag or lastSkillUsageTime): https://developer.amazon.com/de/docs/alexa-skills-kit-sdk-for-nodejs/manage-attributes.html#persistenceadapter
I'm looking at using the Angular Azure Mobile Service Client for a project, I saw this sample code:
angular.module('your-module-name').constant('AzureMobileServiceClient', {
API_URL : 'https://<your-api-url>.azure-mobile.net/',
API_KEY : '<your-api-key>',
});
Is it safe to use the API Key in an AngularJS app like this (or any JavaScript based client)? I'm unsure what someone could potentially do if they had this key?
Found this in the Azure Mobile Services documentation:
With default permissions, anyone with the app key may call the custom
API. However, the application key is not considered a secure
credential because it may not be distributed or stored securely.
Consider restricting access to only authenticated users for additional
security.
It is'Safe' depending on what you are trying to do. Javascript and any keys in it can be read by everyone. This is key is not meant to be used as a password to access important information. Instead it is made to prevent malevolent abuse of your application.
For example if someone is trying to log in 1,000 times per second with every possible password/username combination, they are submitting this key with each request. So you could throttle, or block anyone using this key. Then you would issue a new key to your apps. If you have a system for issuing those keys you might even identify the person that was doing it.
It can stop DDOS, Bruteforce, and some other abuses
We are planning to use mobile sign for one of our application. But as far as I know there are some limitations for signing documents. The vendor we are working has a limitation that you should enter a pin code for every single document and it's attachments. This means if there is a document with 3 attachments, user should enter 4 pin codes in order to complete the mobile sign. This is NOT acceptable, so I wonder how mobile sign works around the globe? I mean other vendors also have the same limitation? Does mobile sign use messaging infrastructure? Would you please give me some information about Mobile Sign?
Thanks in advance.
Best Regards.
Let me explain how mobile signatures work. Based on the process you may infer some conclusion.
Technically the mobile signature is created by a security module when a request for it reaches the device (SIM card,) and after introducing the request to the user with a few explanation prompts, the device asks for a secret code that only the correct user should know. Usually this is in form of a PIN. If the access control secret was entered correctly, the device is approved with access to secret data containing for example RSA private key, which is then used to do the signature or other operations that the request wanted.
The PKI system associates the public key counterpart of the secret key held at the secure device with a set of attributes contained in a structure called digital certificate. The choice of the registration procedure details during the definition of the attributes included in this digital certificate can be used to produce different levels of identity assurance. Anything from anonymous but specific to high-standard real-word identity. By doing a signature, the secure device owner can claim that identity.
Thus, the mobile signature is a unique feature for:
Proving your real-world identity to third parties without
face-to-face communications.
Making a legally-binding commitment by sending a confirmed message to
another party.
Solve security problems of the online world with identity
confirmation (an anonymous but specific identity is often equally
good as a high-standards identity).
Recently I came across an old project for Nokia Asha with app tracking in it.
For every screen accessed by the user a Http request would be made to report to the analytics service and one of the parameters sent was the IMEI in the mobile device.
As far as I know, retrieving information like the IMEI on Windows Phone and iPhone is not permitted but on Android it's still an available function but requires the permission to read the state and identity of the phone which I've been told scare some users.
From what I'm seeing, using this kind of information is being discouraged in which case what alternatives are being more encouraged to implement to identify a device when it comes to analytics services or similar?
You can use a random ID to identify each client.
Odds: With a 64-bit random ID (using, say, nextLong()), the odds of accidental collision are exceedingly small. You'd need 4 billion clients to get the probability of the first accidental collision up to 1/2. This is plenty good enough for analytics.
Implementation: The server can use Java's SecureRandom to generate the ID and put it in a cookie on the HTTP reply if the HTTP request doesn't already have one. Either way, the analytics would associate that request with that cookie.
If the client is a native app rather than a web app, it will need to store the cookie and attach it to future HTTP requests.
Alternatives: If users need to log in to your app, then you can associate usage with their login ID. Otherwise, generate a token.
There are many reasons to not ask the user for their cellphone number including privacy, reliability, and annoying people. Many potential users will drop out rather than enter their cellphone number, while others will enter something like all ones. A random ID will be more unique.
If you need to do account validation via SMS, then you'll have to ask for a phone number. In that case you'll need a privacy policy, a data retention policy and plan, encrypted storage, you'll have to explain it to users, and cope with a substantial fraction of dropouts.
Even if you don't retain the phone numbers, you could construct a one-way secure hash from it to use for the client ID, but phone numbers get recycled so over the long term, random IDs will be more unique than verified phone numbers.
I am working on a WP7 application. This WP7 application will interact with some web services that I have created. I do not want other applications interacting with these web services. The reason why is because I do not want them stealing my data. With that in mind, here is what I'm currently doing:
Connecting to web services via HTTPS
Making my users initially login to the application
Passing the users username / password with each web service interaction
At this time, I don't see what is stopping a malicious developer from creating a username / password combo and using that account in their application to interact with my web services. How do I really lock this thing down?
Thanks!
As a start towards a more secure system you should stop storing the password and sending it over the wire with each request (even if you're using SSL).
If you must pass it with each request, store a salted hash of the password and use that instead.
I'm using a multi layered approach to this problem. I recommend thinking creatively and using a variety of methods to validate that requests are coming from devices you expect requests to come from.
Alternatively, if there is any merit in your scenario, open up your api to 3rd party developers and make this work toward your objectives.
If you do decide to store a key in your app, don't store RAW text but instead declare a byte array of the UTF8 values, this won't be as easy to read.
You can then handshake with your service using a salted hash of the key the first time the app is run, the service hands out another key for the device to actually use day-to-day.
The phone should have an almost accurate time, so you can recalculate the key each day or hour. You can also revoke the key at the server end for just that device.
This API will be useful in ensuring you can blacklist a device permanently.
DeviceExtendedProperties.GetValue(“DeviceUniqueId”).ToByte();
I've not looked into symmetric encryption by you might even be able to use the above unique ID as a private key.
I think the key to success is that first hand-shake, and ensuring that is not snooped. If it's a really important system, then don't use any of these ideas since rolling your own encryption is always flimsy to anyone with serious intent - use well-known methods and read up.
Luke
You could introduce an "Authorized Application ID" feature where the application sends its name or identifier within each HTTP request body. Then on the server side you can verify the application's identity (e.g. store the authorized app ID's in a table). The application ID would be encrypted within the HTTP(S) body.
This would also give you the option of pushing out new application ID's in updated versions of the WP7 application if you wanted to get rid of an older application ID. You'd also be able support new applications on difference devices or platforms in the future.
You may want to look at this
http://channel9.msdn.com/Blogs/Jafa/Windows-Phone-7-Trade-Me-Developer-Starter-Kit