i wrote a sending sms program through wireless messaging in j2me..but whenever i am sending message they are asking permission for sending mssg.
You need to sign your midlet otherwise you will get these security prompts whenever you use an API such as network connection or SMS.
even if you sign your midlet with a 3rd party certificate from Verisign/Thawte you will end up with prompts, the only other suggestion is to use an sms aggregator such as a clickatell to proxy the sms for you
The confirmation is there by design, and from the user's point of view he/she do not want applications to be able to send sms messages without his/her knowledge because they cost money. Your question is in some way like "how can I connect to my neighbour's wifi access point without supplying the required password".
Related
I integrated twillio for signup user in my application. From my application twillio SMS send to User for One Time Password(OTP). If user can verify OTP then and then he can register in my App.
But Sometime Twillio give error code 30004. But I want to send SMS forcefully to user without any restriction. Is there any way to fulfill my requirement.
I also read this page of twillio for my error https://support.twilio.com/hc/en-us/articles/223134167-Limitations-sending-SMS-messages-to-Indian-mobile-devices
But I want to send SMS to user any how.
Twilio developer evangelist here.
I am guessing, since you mention the article on limitations of sending SMS to India that you are trying to send to an Indian device.
As you have read, there are a number of issues with sending to India that all follow from India's classification of services like Twilio as marketing. For this reason, you are unable to send messages outside of the hours of 9am - 9pm and if a number is on the Do Not Call registry your message will never be delivered.
If you are trying to implement two factor authentication for India then I recommend you do so using an authenticator application. You can do this using Twilio's Authy API or by generating a secret and sharing it to applications like Authy or Google Authenticator.
This is more secure than 2FA over SMS and means you do not need to send SMS and rely on delivery in India. Instead the authentication can happen between the server and the device. This is what GitHub did for their 2FA and you can read why about that here.
Let me know if that helps at all.
Error 30004 "Message Delivery - Message blocked" when Sending SMS
If a message you sent is not delivered to the end device and returns a 30004 error code, this means that delivery of your message failed because the destination is blocked from receiving this message
I’m building an application and I’m thinking about asking user phone number to send a verification SMS. Though, imagine if the phone number is cancelled and attributed later to someone else. Then, the new person would be able to connect to my app in the name of the old one...
So is there any way to prevent this behavior ?
I want to make it like tinder : sign up possible by 2 different ways : (facebook connection and phone number) or (phone number and mail)
I have another question : I see that many sms sending services are not free (all of them actually). If I make an api with these services, anyone can send a lot of http request to it and make me pay 0,05€ times 100000000 ? And I can’t rely on IP adresses because with 3G an ip is not associated with a particular person...
To your first question:
You are describing Two Step Authentication (aka Two Step Verification) which you can read about in the Wikipedia page: Multi-Factor Authentication (MFA):
a method of confirming a user's claimed identity by utilizing something they know (password) and a second factor other than something they have or something they are. An example of a second step is the user repeating back something that was sent to them through an out-of-band mechanism.
You are correct that a phone number can change owners (as can an email address though over a longer time period on average). You are using their phone number as that out-of-band mechanism described above.
If the user has recently authenticated with their password, when you send the user an out-of-band code and they re-type that into an input box you have some degree of confidence that the end user both knows the password and has access to the SMS message and are choosing to trust that association.
You will need to consider if, and for how long, you can trust that association within the security context of the use case.
For example, adding two step verification when detecting the end-user has just authenticated on a device you have never seen before is a nice additional protection. However, using the out-of-band SMS verification in account recover could open up a big security hole. You do not want to bypass the authentication with something they know (password) in a password reset flow by simply having access to that SMS number. SMS is also not an appropriate mechanism for one-time-password (OTP).
If you want to offer you users more protections on their accounts look into implementing true MFA with software tokens (eg. Google Authenticator, Authy, etc.) and hard tokens (eg. FIDO U2F devices such as Yubikey, Google Titan, etc.).
To your second question:
You are correct, IP-based limiting is insufficient. With SMS services you are likely going to be making a server-side API call to the SMS provider. First check to see what security features your provider has out of the box. Next, protect your endpoint that is triggering the API calls to the SMS provider.
Rate limit the number of SMS messages to any one given recipient (eg. no more than X SMS messages to a single number per Y minute window)
Rate limit the number of SMS messages one person can make to different numbers (eg. no more than X different phone numbers per user per day).
Do not allow unauthenticated requests. The user should have already completed the first authentication step (something they know eg. username/password) before performing the out-of-band SMS step.
Protect the SMS form from Cross Site Forgery Requests (CSFR). Your back-end should only make the API call to the SMS provider if it knows the request came from your front-end and not another host.
Protect the SMS form from bot attacks. There are many approaches with Google ReCaptcha being one of the more common.
I have a social networking website developed in php which is hosted on the server. Here people can talk to each other through messages.
I want to send and receive the messages, to the other users through google home. It is not like a chat bot. But here, the first user will send message from google home to the website and then the second user will send the message from the website to the first user who will receive it through google home.
Can this be achieved? Do I have to develop some kind of mobile App, so that user has to send the message to the mobile app and then the app sends the data to the server.
or do i have to use the webhook which is available in api.ai?
Any help will be appreciated.
You do not need a mobile app - it sounds like most (but not all) of what you're trying to do would be handled using API.AI's webhook Fulfillment.
However, you're also trying to do asynchronous operations (send a message or a notification to Home without the user prompting for it). This currently isn't possible - you can currently only send a message in response to the user taking some action.
One possible workaround for you is to allow the user to ask "how many messages are waiting for me" or something similar at any point. You can also play multiple messages in reply to a message they might send. However, you have limits (about 5 seconds) on how long you can wait to send a reply to a user instruction.
You can implement a chat bot e.g. via Dialogflow (former api.ai), however you can just react on inputs. You cannot push a message on Google Home (yet). So you could the bot read your mailbox but not implement a chat.
I am developing a project where I need to send an sms to the contact and if the contact doesn't receives the sms I have to send him another or choose another contact. So, for notifying my midlet of successful sms delivery i'll need to receive and read the sms delivery report.
How to read delivery report using j2me? Or Is there any other way to achieve this?
If you put your application on the Nokia store it will be automatically signed by Nokia to the 3rd party trusted domain, so the prompts will be less. Also i think if you implement SATSA JSR http://en.wikipedia.org/wiki/Security_and_Trust_Services_API_for_J2ME you can talk to the Sim card and get relevant information maybe on delivery of SMS also, but you need the app to be signed to the operator domain for permission. On the other hand, if you have an SMPP connection to a server you can send SMS to users with a port number and also view the message status there.
I am creating a j2me application for mcommerce, which uses mobile internet(gprs). I wanted make it more secured by binding the application to the SIM card and the device. That is a user should be able to login to the system, only using his/her SIM card or from the registered mobile number.
To achieve this I need to fetch the mobile number.
So, on login i thought of Triggering an SMS from the server with a key, which the application reads and uses the key for the entire session. Here the challenge is, that sms should not go to the inbox.
Any suggestions pls?
Yes it can be achieved using the Wireless Messaging API. Have the MIDlet set up a server connection on a chosen port number, then send the SMS to that port number. It will go straight to your app, bypassing the inbox. If you use the Push Registry, you can even make the SMS start your app if it is not running.
It doesn't matter if the user sees the number in his/her inbox.
As long as the key is only used that session, it is her/his responsibility to not share the key with others.
The one thing you make sure is that ONLY the person who owns the SMS phonenumber gets the key and is able to log on.
This doesn't take care of the phone being stolen though.