1 2 3 83 Previous Next

SAP for Mobile

1,233 Posts

SAP Afaria 7.0 SP8 has been released and is available for download in the SAP Support Portal.

Please check the Readme and Product Documentation for further details.


If you would like to stay tuned on the latest news around Afaria, you may want to watch this wiki page to receive update notifications.
Hint: You need to be logged on in order to have the "watch this page" option available.

Hello Afaria-Friends,


this compendium will cover the usage of SMTP notifcations (send message as email) with Afaria to mobile devices. The available Afaria documentaion will not explain all the details in this way for this part.


Link: http://wiki.scn.sap.com/wiki/x/8YcoGg


cheers Chris

Hallo Afaria-friends,


I'd like to share with you a Wiki page which is covering multiple examples of how to use Afaria with certificate based authentication (CBA) for Wifi enterprise connections and Exchange Active Sync (EAS).


link: http://wiki.scn.sap.com/wiki/x/1ZD3GQ


cheers - Chris

The October/November release of the iOS client has been released to Apple and should appear on the App Store for general availability soon.  This client is intended for use with SAP Afaria and SAP Mobile Secure.


The client release version is 8061 and the client has been enhanced to support additional languages.   Please see the following KBA for the release notes on this version.


October/November iOS client release - Afaria

The SAP mobility team has been very busy building a new cloud-based service designed to optimize the mobile experience for companies deploying SAP Fiori. This solution provides a no-code option to help you quickly build mobile SAP Fiori apps using SAP technologies and tools that connect to on-premise SAP environments. The completed SAP Fiori apps can then be deployed to end users via any Mobile Device Management (MDM) solution including SAP Mobile Secure, SAP Afaria or Microsoft Intune.


Through our long time partnership with Microsoft, SAP has been keenly interested in finding ways to interoperate SAP Mobile products with Microsoft products. Early in the process of developing this solution, we recognized that SAP and Microsoft have a number of customers in common, of which some have chosen to deploy Microsoft Enterprise Mobility Suite (EMS).


You will soon be able to create custom SAP Fiori mobile apps and deploy those apps to end users via Microsoft Intune (you can also read the Microsoft blog.) Using the SAP Fiori mobile service, SAP will enable you to build custom mobile apps that combine SAP Fiori HTML5 apps with additional native capabilities using the Apache Cordova framework. During the custom app build process, which is initiated by the customer, we will dynamically retrieve third party Cordova plugins, such as a Microsoft Cordova plugin encapsulating the Intune SDK, that allows the app to be managed with Microsoft Intune.


Our team's goal is to help you mobilize and deploy your custom SAP Fiori apps across diverse environments. SAP Fiori mobile service (which was recently announced at SAP TechEd) and SAP Mobile Place will soon interoperate with Microsoft Intune. We believe that allowing you to build rich mobile applications using SAP’s mobile offerings as well our partner’s technologies is the best way to leverage your investment in SAP Fiori apps while offering a great mobile user experience.


We accomplish this process by simplifying how custom SAP Fiori apps are first published to SAP Mobile Place, SAP’s enterprise app store. We then further distribute the apps via Microsoft Intune.


The key aspects of this interoperability effort are:

  1. Using SAP Fiori mobile service, you will be able to add Cordova plug-ins from third parties, generating a custom SAP Fiori app.
  2. SAP and Microsoft have been building and testing a Cordova plug-in that encapsulates the Intune SDK. Once this Cordova plug-in is added as part of the custom SAP Fiori app (by you), it can be managed in an Intune EMS environment.
  3. You will be able to include the Intune Cordova plug-in into a custom SAP Fiori mobile app, build the app and then publish the custom SAP Fiori app to SAP’s enterprise app store, SAP Mobile Place.
  4. IT administrators will then be able to use Microsoft EMS to deploy the custom Fiori app to their end users.


We expect to roll out this integration gradually, with a beta program beginning in early 2016. If you are an SAP Fiori customer who is considering or has already deployed Microsoft EMS and would be like to be considered for our early adopter program, please contact me via email at Milja.Gillespie@sap.com.

Hello SCN Community,


i want to share a new Wiki Page with you: The iOS Certificate Compendium


This Wiki should help you to understand with which certificates will you get in touch when working with iOS devices in an MDM Solution like Afaria and Mobile Secure Cloud Edition.



Your Feedback is much appreciated.


Thank you

Andreas Kuhn

Executive Summary

Recent events involving misbehaving apps on Apple iOS highlight some of the challenges Apple has in ensuring that third party apps behave so that they do not impact other Apps or access sensitive data controlled by Apple APIs. SAP mobility customers with higher security requirements can no longer assume that malicious behavior of other apps is technically restricted, and should consider implementing solutions like SAP Afaria or SAP App Protection by Mocana to ensure the confidentiality and integrity of the data in use by their mobile apps and web applications.



I am still struggling to come to wrap my head around the implications of the recent cases of application misbehavior in the Apple mobile app universe – XCodeGhost, YiSpecter, and now, the YouMi-related apps pulled from the App Store.


A fundamental assumption in many SAP mobile deployments is that Apple, Google, and other mobile OS manufacturers have spent considerable time locking down their OS to control third-party application developers and keep them in line.  In the case of Apple’s iOS, other apps installed on iOS devices are supposed to play by the rules; if they don’t they won’t be approved by Apple in the app store, or in the case of XCodeGhost and YouMi-related apps, will be pulled retroactively. We assume that our apps and app data are safe in their sandbox, safe from the prying eyes of other apps.


Unfortunately, the YouMi incident has caused me to come to the conclusion that this is no longer a safe assumption. People deploying SAP apps or SAP web applications to mobile devices should not assume that this data is protected from other apps running on the device, especially in a BYOD scenario.

Background Information - XCodeGhost

The two most problematic incidents leading to this conclusion are the XCodeGhost and YouMi apps that were pulled. In the case of XCodeGhost, the Apple iOS SDK wasn’t available for local download in China – it had to be downloaded all the way from the mothership in Cupertino, and for app developers in China, this was extremely slow. To get around this, Baidu and other providers helpfully cached this locally on Baidu servers local to China, making the download much quicker. The problem was, someone had tampered with the SDK and added “hooks” that sent sensitive, device specific info to a mysterious group of servers. At the time, the hooks in the modified SDK allowed these attackers to access private APIs that gave the SDK distributors access to sensitive info, including the device ID and paste buffer – sensitive info that apps playing by the rules should not access. Apps developed using this compromised SDK have been pulled from the app store by Apple.

And then there’s YouMi

SourceDNA has a great writeup on the problems with the YouMi apps recently pulled by Apple – there are 250+ affected apps in total. YouMi is an advertising platform that makes an SDK available to mobile developers. Mobile developers wanting advertising revenue from the YouMi network could easily incorporate YouMi into their apps, simplifying the process of monetizing their user’s eyeballs.


The problem, SourceDNA found, was that, again, the apps incorporating YouMi didn’t behave by the rules. The YouMi code accessed private APIs that, according to SourceDNA, sent the following sensitive data (from Apple’s perspective) to YouMi servers:

  • A list of installed apps
  • The platform serial number
  • Device enumeration
  • Generated a numeric value associated with the Apple ID


Although YouMi has publicly disputed some of the specifics, as a result, hundreds of apps incorporating the YouMi SDK have been pulled from the App Store.


What’s concerning is that SourceDNA’s solution for app developers to avoid this in the future points to a more serious problem in iOS.

SourceDNA’s Solution

The solution SourceDNA is proposing, and offers to app developers via their SearchLight offering, is a deeper level of validation than Apple currently does. In order to understand the validation process and why it’s important, it helps to understand some of the fundamental architectural issues that Apple is facing. The challenge is, Objective-C based iOS apps are supported in the iOS app model. For Objective-C based apps, Objective-C calls to methods are passed as strings through objc_Send, and by design there is no technical restriction on what can be called. Evidently, Apple addresses this by 1) de-documenting and obfuscating their private APIs, and 2) by statically analyzing App Store candidates, looking for strings calling private APIs and methods. (Caveat: I am an InfoSec practitioner. I am not an iOS developer, nor do I play one on TV). What SourceDNA found was that, in the case of YouMi, the method calls were obfuscated and assembled pseudo-randomly from the code in such a way that the protected APIs did not appear as strings in the source code, and so were able to pass Apple’s static analysis checks.


SourceDNA’s solution is their SearchLight offering and is the next logical step: analyzing these apps at for private or protected method use runtime. Basically, they execute and exercise the code, looking to see if protected APIs are called. If they are, the app developer knows that some framework or SDK they are incorporating into their app is misbehaving, and proactively drop use of that SDK or framework prior to seeking App Store approval.

The Fundamental Problem

Is anyone else getting a sense of deja-vu here? Does all of this sound familiar? Change the name of “Searchlight” to “Antivirus Scanner” and change the term “protected method use” to “malicious code”. We have been here before, and we can pretty much predict where this trajectory will end.


Oh, there are differences between virus writers and malicious iOS app developers. Virus distributors had almost zero negative consequences if their code was detected; App store developers stand to lose out on legitimate revenue if their apps are pulled. The risk of getting caught is higher, and the cycles to evolve counter-detection measures in your code take longer because each cycle includes registering at the app store, getting your app approved, and getting it installed on devices. But this game will continue to evolve; malicious app writers will get better at covering sensitive API/framework/method use in iOS. And as Steve Gibson of grc.com and “Security Now” pointed recently, the protected methods don’t even need to be in the source code in any form – private, privileged methods can be retrieved from an external server at runtime and then used by the app to form the call to that method. This is a logical next step and it will make detection of misbehaving iOS apps extremely difficult to detect once implemented by the black and gray hats.

An aside - reverse engineering private APIs used to be a dark art, but guides on how to reverse engineer these are in the public domain. I've included a couple in the references section.


What this Means for Me and my Mobile SAP Deployments

At the end of the day, developers of SAP Mobile applications should assume that other untrusted apps can view and even use mobile SAP application data. The types of behaviors observed today in PC-based malware are within the reach of a malicious iOS app. Developers deploying mobile solutions should assume the same level of confidentiality for application data that they assume for semi-trusted or untrusted PCs.


If they:

  • Store sensitive data
  • Process sensitive data


  • Transmit sensitive data (and yes, this includes usernames and passwords)


...then controls ensuring the confidentiality and integrity of that data are important part of the security controls of the solution. To that end, a couple of options are available to SAP customers to help address this risk:

  • For Corporate owned devices, SAP Afaria can be deployed to whitelist apps that can be installed on corporate owned devices. This greatly limits the likelihood of a malicious app being installed on their population of mobile devices. Note that other MDM solutions can be used to whitelist approved applications as well.
  • In a BYOD scenario, this is not always feasible. This is where SAP App Protection by Mocana comes in. SAP App Protection by Mocana assumes that the device is semi-trusted or untrusted, and so the Mocana wrapper encrypts stored and transmitted data, using Mocana-specific encryption keys and app-initiated VPNs. For SAP customers deploying apps with sensitive data on semi-trusted devices, SAP App Protection by Mocana is a control that balances the needs of the user community while helping ensure the confidentiality and integrity of mobile app data.


Remember – from a security perspective, the infrastructure for mobile solutions extends to the mobile devices themselves. And mobile solutions need to incorporate technical controls that not only address the threats and vulnerabilities we know about today, but should include the vulnerabilities we won’t know about until later on in the lifecycle of the solution – in 2018, 2020, and even beyond. Either one of these controls will greatly expand the options an organization has to adapt changes in the threat environment.


Good luck out there!


YiSpecter: http://appleinsider.com/articles/15/10/05/apple-acknowledges-yispecter-ios-malware-says-issue-unlikely-to-affect-most-people

XCodeGhost: http://appleinsider.com/articles/15/09/24/apple-lists-top-25-apps-affected-by-xcodeghost-malware-infiltration

YouMi: https://sourcedna.com/blog/20151018/ios-apps-using-private-apis.html

List of apps affected by YouMi: https://sourcedna.com/blog/assets/sourcedna_apps_private_frameworks_20151014.csv

Steve Gibson’s take on Verifying iOS App Behavior: https://www.grc.com/sn/SN-532-Notes.pdf

Cool articles on reverse engineering iOS to find undocumented features:



Regular readers will figure out that this, being my 2nd blog posting around Two-Factor Authentication (2FA) that something must be up with me, SAP Mobile Services, and 2FA.  You have certainly guessed well.  These postings are the first in a series outlining the benefits of 2FA for both end-users and enterprises, and soon, we’ll provide more details around our new, portable 2FA solution from SAP Mobile Services.40012_SB_figure.jpg

Have you ever forgotten a password?  I know that I have.  I do all the time, in fact, although over the last year or two, I’ve gotten better at managing my password schemes (yes, I have schemes that I’ve memorized to generate new passwords).  But forgotten password recovery is a “popular” mechanism in which bad guys can gain access to your account. So, we must incorporate a number of checks to disrupt and prevent attempts to gain access to accounts.


While there are a number of initiatives ongoing to actually replace passwords, the reality is that passwords as security mechanisms for online accounts will be with us for some time to come. Thus, we need to provide reasonable security for those of us who will forget these passwords.


During an appropriately secure password reset, part of the process is to provide an “out-of-band” channel. This is where 2FA plays a role to mitigate a hacker who may have compromised a user’s account.  In fact, leveraging the forgotten password recovery mechanisms are common ways that hackers can get into your accounts – especially if they can access your emails. That’s why, first and foremost, it is a good idea to have your email account(s) protected with 2FA. You need to protect your email accounts and 2FA is a great way to do it.


Many password recovery solutions in place actually do a good job of asking for details that only the account owner would know – like for credit cards with the various codes that are only visible to someone in possession of the card.  The passwords should (and do) expire and need to be reset after some period of time.  But many, many more accounts will simply ask a few (or no questions) and email a link to change the password or send a new (plaintext, no less) password through email.  This is just asking for trouble.  Email is not secure and not encrypted.  Now this post is not about all of the aspects of resetting or recovery of a lost password.  But one thing to keep in mind is that it isn’t about recovery of a lost or forgotten password.  In reality, the password should never be recovered, but always reset.


There are two very good references that I’ve found that I would point you to:


Both sites offer outstanding guidelines in easy-to-understand language about the best practices for resetting passwords.   One of the common elements of both of these guides is that they recommend incorporating two-factor authentication. The point is that most of the password reset process is based around something the user knows. The 2nd factor leverages something the user has – a mobile device or a “side-channel” token as the OWASP describes it.  One of the guides notes (correctly) that sometimes the device that receives an SMS with a token is the same device that the consumer is using to also try to reset the password.  While it is the same device, it is a phone number-based channel so OWASP’s point of being a “side-channel” is correct.  To add further security, the code generated should only have a validity period of a short time – say 5-10 minutes before it expires.


Some best practices guidelines question the reliability of sending a token via SMS due to delivery problems. That may have been an issue in the past; however, we’ve found that as long as the message is delivered through proper mobile operator SMS delivery connections to validated phone numbers (the phone number should have been validated with a verification code during registration), then the overall reliability goes up considerably – well over 95%.


Certainly 2FA for password resets and various other functions is not 100% immune from sophisticated cyber criminals.  But for the most part, the bad guys would have to (1) have your mobile device, (2) have the passcode to your mobile device [you do have one, don’t you], (3) have access to your email / account / password, (4) know or able to guess answers to secret questions.  Number 3 is pretty easy and certainly a gateway into compromising accounts; however, also obtaining 1 and 2 becomes quite rare. There are other vectors into being able to compromise mobile devices in order to steal 2FA codes, but these are also exceedingly rare. That notwithstanding, let’s not lose sight of the fact that the inclusion of an alternate or out-of-band channel such as 2FA over SMS can greatly increase the security of a properly-designed password reset function.



SAP Support tries to be proactive in giving resolutions out to the customer to be readily available before the need arises.


Based on some internal/external installation of SAP Work Manager 6.0, 6.1, 6.2 and later the following KBA/SAP notes articles will help users deploy and troubleshoot time zone successfully.


These SAP KBA/Notes are compiled solutions used to solve past reported problems. The goal of this Troubleshooting page is to have at least one landing page that can be bookmarked or referred to if a user has issues with time zone or time conversion in SAP Work Manager for SAP backend.


SAP Backend:


  1. SAP # 2105611 - Agentry takes default timestamp as GMT - SAP Work Manager.
  2. SAP # 2185367 - SAP Work Manager error on transmit - AddLaborTime - Actual date(s) is in the future.
  3. SAP # 2159554 - SAP Work Manager - Creating workorder in morning and confirming the same in the afternoon results in LaborAddSteplet End date is before start date.
  4. SAP # 2161473 - SAP Work Manager - Creating workorder in morning and confirming the same in the afternoon results in error on transmit
  5. SAP # 2157527 - SAP Work Manager - LaborAddSteplet - End Date before Start Date.
  6. SAP # 2069376 - The start and finish time for SAP Work Manager are captured incorrectly for operation level assignment
  7. SAP # 1813025 - Client Time Zone is not recognized and no alias was found in TimeZoneAliases in Agentry.ini
  8. SAP # 2211638 - ContractStartTime and ContractEndTime is blank - SAP Work Manager Customer Service 2.1
  9. Wiki - Set Up Time Zone Alias in Agentry.ini Configuration File

The goal of the product team is to merge most of the fixes in newer releases of SAP Work Manager. Please read each of the issues accordingly based on their known versions and check the SAP Work Manager release notes if they have applied the said fixes properly.

Known Limitation:

2233697 - Limitation: Workorder time confirmation duration or time lapse (Start Time and Finished Time) - SAP Work Manager 6.2


As with any known limitation, we continue to improve the product based on feature request and business needs. Any feature request needs to be given to the SAP Account Executive to tie in the request with your company. We hope the next releases improve each of the functionality as needed.


We (SAP Mobility support) will try to update this when we have any new items or found old items that can belong in this page.


SAP IBM Maximo Backend:


  1. 1922535 - StartTime using transmit time when placed on Hold after transmit with Started status - SAP Work Manager for Maximo


Other SCN References:



Best Regards,

Mark Pe
SAP Platinum Support Engineer (Mobility)

All Agentry/Maximo users,


SAP Support tries to be proactive in giving resolutions out to the customer to be readily available before the need arises.


Based on the July 31, 2015 requirement to upgrade (end of extended maintenance) Agentry 6.0.X (and earlier) version to SMP 3.0, there is a need to study the new platform on how to integrate it with IBM Maximo (SAP Mobility Syclo - Maximo products). From the first analysis and integration there were incompatible libraries and deprecated Agentry functions between Maximo and SMP 3.0 (Agentry). SAP worked closely with the IBM Maximo, SAP Work Manager and SMP 3.0 developers to create a new solution and instructions on how to use LDAP in SAP's Work Manager for Maximo 8.X and SMP 3.0.


We appreciate all the partnership given by our customers and SAP system integrator companies (Including Maximo team) as we continue to improve our products and help the user community mobilize their solution. With this new knowledge, users of IBM Maximo (LDAP authentication) can integrate their SAP Work Manager for IBM Maximo LDAP properly using SMP 3.0 (Agentry) functionality.


Please reference the official guide: SAP Note # 2237514 - Adding LDAP support to SAP Maximo Products in a Websphere 8.5.x Landscape (and their corresponding reference notes).


Best Regards,

Mark Pe
SAP Platinum Support Engineer

Today at SAP TechEd in Barcelona, SAP announced plans to enable customers to deploy and consume SAP Fiori apps across both on-premise and cloud architectures while delivering superior mobile app performance. This news involves two new HANA Cloud Platform applications services. The full press release can be read here.

First, the cloud edition of SAP Fiori (now in controlled availability) is a HANA Cloud Platform service that enables you to simplify the implementation and adoption of SAP Fiori. The great part is that it runs in the cloud yet consumes business data from your on-premise systems.

  • Learn more about the features of SAP Fiori, cloud edition here. You’ll find a feature list, see a product walkthrough, and watch videos.
  • Watch the video released at SAP TechEd Barcelona showing how SAP Runs SAP Fiori, cloud edition.
  • Create your own demo account here.

Second, I’d like to spend more time on the SAP Fiori mobile service. I’m personally excited to share details of this new offering that I’ve been working on for the past 6 months. We recognized early on that mobile is a required use case for SAP Fiori deployments – over 80% of customers who have downloaded Fiori want to use it on mobile devices. Our goal with this product is to help you optimize SAP Fiori for mobile performance and productivity – to simplify the way you package, customize, secure, connect, test, distribute, and monitor SAP Fiori apps.

As your Fiori initiatives gain momentum, you will likely face (or are already facing) the challenge of how to deliver SAP Fiori functionality in a way that satisfies your mobile users. They want high performance apps yet at the same time they expect to leverage the features of mobile devices like integrating with camera, location, and calendar. If you plan for mobile when you start your SAP Fiori projects you’ll be one step ahead of the game. 

So what exactly is SAP Fiori mobile service? Simply put, it is a HANA Cloud Platform service that helps you optimize SAP Fiori for mobile performance. SAP Fiori provides the best possible user experience; the mobile service takes you beyond accessing SAP Fiori apps from a Web browser and provides secure and streamlined integration with complex deployment scenarios.

I think one of our customers (Kunal Gandhi, SAP technical lead at ESRI) stated it best: “SAP Fiori mobile service can help us simplify our infrastructure in the cloud while still allowing us to integrate with our on-premise back-office systems. Leveraging a single solution to build, secure and distribute SAP Fiori apps will allow us to concentrate on app development with a focus on the UX while helping to streamline the process to mobilize apps for our end users.”

I’ve put together a video demonstrating the product and highlighting the key steps to managing the entire app lifecycle; first building the Fiori mobile app, then testing that app, publishing the app to an enterprise app store, and finally monitoring its ongoing usage.

Please reach out to me via email if you'd like more information.

To All SAP Agentry/SMP 3.0 users,


SAP Global Services and Support (GSS - One Service) tries to be proactive in giving an announcement to the customers prior to more issues to show. We value your time in using our products and we always try to fix issues and give the best solution out to the customer.


Unfortunately based on some internal and external installation of SAP Mobile Platform/Agentry Products in SMP 3.0 SDK SP10, we have found a complex table drop down duplication issue.


This is a known issue and regarded as a critical issue and we have a fix in code review and will be released shortly. This is important as we have recently released SMP 3.0 SDK SP10 to support iOS 9  for iOS devices.


Details of the issue are under: SAP KBA # 2238294 - Complex Table Drop Down duplicate entries in WPF, iOS and Android - Agentry / SMP 3.0 SDK SP10.


Hope this clarifies some of the reported issue. Please bear with us until we have released the solution soon.


Reference article: Broadcast Announcement: Agentry SMP 3.0 iOS 9 c... | SCN


Best Regards,

Mark Pe
SAP Platinum Support Engineer

The October of the SAP Afaria Client, Version 8684 has been posted to the Google Play store. This client is intended for use with both SAP Afaria and SAP Mobile Secure. This release supports Android M (marshmallow).  The release notes are posted in the following KBA:


Current Android Client release - October 2015

In the past few years, the incidents of major data breaches as well as hacking into personal accounts for not only public people, but also not-so-public people, seem to be on the increase.  In June, 2014, McAfee recently published a study indicating that hackers are costing consumers and companies between $375 and $575 billion... annually!  Furthermore, losses connected to personal information, such as stolen credit card data, have amounted to over $150 billion.  We’ve all had instances of unsubstantiated charges appearing on our credit card statements. These are usually handled by the credit card companies, with little or no liability for us personally.  I am hoping that as contactless payment options and EMV cards become more ubiquitous, we will start to see the great reduction or elimination of these types of fraudulent charges and activities.


But, EMV cards and contactless payments don’t do a lot to protect our online persona – and think about it... we have many of them, with many passwords.  Do you remember them all or are you using similar or the same passwords for multiple accounts? How many of you have credit cards or even banking information on file with an online retailer?  How secure is your access to that account?  My guess is that most of you use a user ID and password.  Many banking and financial services (including credit card companies) offer two-factor authentication (or 2FA). Except for a few cases, most online retailers don’t offer 22FA Apple Watch.PNGFA as an option for logging in and other high-value transactions.  If they don’t, they should.  If you don’t, then you should.  2FA is one of the most simple, yet most valuable methods to help protect your identity.


Many banks have taken the initiative and provide 2FA capabilities to their customers if, for example, you log into your online bank account from an IP address that you haven’t used before. That’s a huge protection for you. Have you provided your mobile number – e.g. the number where you receive texts?  Don’t be afraid to share that.  Your mobile device is “something you have” – that is one of the factors in two-factor authentication. Typically the first factor is something you know – e.g. your password.  An alternative might be something you are – like a fingerprint. My point is that if you are given options to set-up 2FA, then do not hesitate.  You will be doing yourself a huge favor.  If an online retailer or whomever does not offer it and relies on security challenge questions (which are problematic and not secure, according to Google research) along with a user ID and password, please ask them to consider supporting 2FA.


2FA SMS 1.PNGIf you have a public persona – such as Facebook, Twitter, or some other social media, you should highly consider using 2FA if it is offered. Codes are sent to your mobile device if a login is attempted from a device or browser that is not recognized by the service. Therefore, should your user name and password ever be compromised, you still have some level of security, as you should still be control of your mobile device.


Two-factor authentication is simple and easy for the consumer. In most cases, it will be a multi-digit code sent to a mobile device - typically through SMS.  Whatever website being visited will make it clear that they are sending such a code and provide a location to enter the received code within a short time limit. Too many failed entries will lock out the user.  There’s no really good excuse not to use 2FA when offered.  Sites where financial information are kept and accounts that offer users a public persona should always be protected – not only for the protection of the users, but the enterprise as well.


Personally, I am sick and tired of hearing about data breaches and identity theft when there are so many tools today to prevent.  With so many enterprises being compromised, many times the breach was simply caused by lax security measures and not adhering to well-known standards such as 2FA (and of course PCI DSS) and it only takes one employee to enable a hacker to compromise accounts of millions.


What are your thoughts?  Are you using 2FA when offered?  If not, why not?  If so, is it your choice, or does the organization you are working with (as employee or customer) mandate it?


Filter Blog

By author:
By date:
By tag: