Hi, (updating Jose Rodriguez email address and adding Jorge Vila)
It's been a long time Š nice to talk to you again :-) Inline El 14/06/13 17:06, "Fernando Jiménez Moreno" <[email protected]> escribió: >I've checked with TEF side that unfortunately the binary SMS option is >not possible :(. It is currently not supported by default in every >country (at least for TEF) and it seems to be supported only for SMS MT. >We could still do it for some countries and with a mix of text SMS MO + >binary SMS MT, but I don't think that's a good solution as the SMS flow >is supposed to be the fallback for other authentication mechanisms that >are not available in some countries (apart from allowing the >authentication for the WiFi use case), so I would rather do this fallback >as universal as possible. David>> yes, I agree. We could get binary MT SMSs for some Obs via the APIs we currently use, but not for all countries. Additionally, binary SMSs are usually used as push notifications to wake up applications, so it is restricted to the MT direction. > >I've also been told that there is no confirmation that an SMS MO sent to >a short code is 100% secure as it depends on the specific carrier/country >network and how they protect their interfaces (David Lozano might >elaborate more on this). David>> We did some investigations some months ago when we first discussed about the silent SMS-MO flow. Our conclusions were: - SMPP, the telco level protocol used by SMSC to exchange SMSs, has only one "source_address" field that accepts alphanumeric values (it can even be a display name) [2][3]. An entity that can set this parameter at SMPP level can thus set whatever value it wishes if no further restrictions apply. - given the existence of SMPP brokers and aggregators in the Internet, MOs are NOT secure for destinations that are long numbers (i.e. hackers can set the origin you wish in messages sent to regular phone numbers). This is a problem Twitter had some years ago. - however, the situation with short codes as destination is different, as short codes are private "addresses" that can be routed only within the operator network (they are not globally routable) and, therefore, this limits very much the scope of possible attacks. In the end, the security of using MOs to identify sender MSISDN actually depends on the security at the network level and who and how can connect to the SMPP interfaces. As you may guess, we have not been able to make a security audit of all Telefónica operator's networks regarding SMPP, so we cannot 100% guarantee the security of only using an MOs Š but we can't deny it either and we haven't found any bad experience so far with this approach. > I've also been told that for other partners an MO only flow is secure >enough though and they have a similar flow based on SMS MO only. David>> Yes. Two BIG partners are using only MO SMSs to authenticate users. Jose and Jorge (in CC) are leading this solution that also integrates with MobileId. We also checked with Bango that they were using this approach for some countries and had not found problems so far >In any case, since there's not an strong assurance about this, my >preference is to expose a "doSilentSMS(..., bool)" function with a >boolean flag that allows the payment provider to choose between an MO >only or an MO+MT flow. Some of the required pieces for this might also >benefit us in the future for other use cases like the Cost Control app, >where an SMS flow is also required. I will start discussing the >implementation details at [1] as soon as possible (probably after Taipei >work week). David>> looks reasonable. Best, David > >Cheers! > >/ Fernando > >[1] https://bugzilla.mozilla.org/show_bug.cgi?id=816564 [2] http://www.routomessaging.com/dynamic-sender-id-service.pmx [3] http://camel.apache.org/smpp.html ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx _______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
