» There is no doubt that over time, people will rely less and less on passwords. People use the same password on different systems, they write them down and don’t respond to the challenge for everything you really want to secure, »said one Bill Gates several years ago in 2004, and between us he was, and continues to be, right. The only concern is that the latter are increasingly present and that multifactor authentication is far from widespread.
Some banks still continue to use web-based forms with account and password entry to allow customers to access their account management without any further identity checks. Closer to home, our mobile messaging applications, our older Windows applications, often use authentication methods that rely solely on a username and password. Meanwhile, companies such as Yahoo, Equifax or Amazon have been robbed of some of their customers’ credentials.
Our daily mobility also invites us to pass our data on globally open networks whose level of security is totally unknown to us. The encryption of the flows (Https) in these public environments is only a last resort because it is so simple for a hacker to place himself between you and the requested service and intercept your exchanges. Bill Gates was, and continues to be, right. But how to do without a password, is this simply possible?
As part of a deployment of O365 services we did some tests that showed despite all the techniques in force, that it was not as simple as that. Come on, we’re showing you all this.
In the Microsoft environment and especially in the Office365 environment, there are several authentication modes that are either agnostic to the environment and therefore used in other environments, or directly from Microsoft environments (NTLM). The oldest method of authentication and therefore the most obsolete in view of the risks involved is basic authentication.
The basic principle is to send the user’s account and password to the services concerned within an encrypted channel (Https). This basic authentication is the simplest method and is widely used by almost all native email applications on Smartphone. It is mainly this obsolete method that continues to pose security problems. Get rid of it? let’s see what modern authentication offers us.
The Modern authentication
The ideal solution to date is to avoid sending connection information to the services concerned, i. e. Office 365. To do this, the identity federation, which consists of delegating the authentication of accesses not to the entity responsible for the service but has a service that you host and that remains under your responsibility. This will allow the user to present their service access ticket without having to present their login information. How does it work? Let us take an example.
Eric Blanc wants to board the 0365 plane and shows up at the counter without a boarding pass. Boarding crew reject him and invite him to check in. Eric Blanc will therefore prove his identity to this organization (different from the one operating the aircraft) and will obtain a boarding pass. Eric will leave again to embark with his boarding pass issued by the check-in services that the company 0365 trusts and in fine, will embark without communicating his identity to the company 0365. In modern authentication it is almost the same principle, as shown in the diagram below.
Eric asks for access to his mailbox but doesn’t have an access token (No Token), the famous boarding pass. The Exchange Online (EXO) service tells him that he has to contact the Microsoft authentication service (401: Need token from AuthUrl).
The client is then redirected to a login page hosted by Microsoft, which prompts the client to enter its login ID in the form xxxxxx@company name. (Show Login Page).
Once the user has typed in his username, the right part of his username will allow Microsoft services to identify that this domain has a federation of identity. It will then return the user to the different login page, which it is hosted under the responsibility of your company.
The user will authenticate himself by communicating his login information (Enter UserName / Password). Your identity provider (IdP, here your ADFS Active Directory Federation services) will validate this with your Active Directory and communicate a SAML token to the user telling him/her to report to the service that delivers the token (boarding pass).
The user will present his SAML token to the service that delivers the access Token (boarding pass) i. e. the Security Token Issuing Service (STS) and will receive two access tokens. An access and a token to renew this access token (Refresh Token). Once equipped with these access tokens, the user will be able to access his mailbox at the door of the service (Exchange online).
The next time the user will present his access token without necessarily redoing all this way.
If at first glance this method may seem complicated to you, it avoids to send information of connection to the platform which hosts the service that is Microsoft, what is the objective.
But are you totally out of trouble? Not completely in reality. The first constraint to take into account is the customers you use and who will be able to manage all these comings and goings described above. In the Microsoft universe, not all customers know how to manage the authentication mode called Modern Authentication. Microsoft publishes the list of compatible clients on the following link:
As for applications of mobile messaging native to IOS or Android systems,’ therefore not Microsoft’s responsibility), they will send their connection information in basic mode to Microsoft services that will process this information and ask your identity provider (IdP) to validate access to the service. Other applications like Outlook 2010 SP2 will do the same. The figure below illustrates a basic authentication attempt generated by a client that does not support modern authentication and decoding of login information.
How do we stop it?
Or rather, how to prevent a user from taking his mobile phone and trying to configure it with the native application to synchronize his messages? It is simple, it is not possible. The access in basic mode for messaging is not currently disabled on the Microsoft environment however and thanks to recent developments of Microsoft teams, official mobile applications Outlook Skype etc… they manage perfectly and by default Modern authentication. I therefore urge you to support only these in your deployments and strongly urge your users to use them.
Banning basic authentication on the Office 365 environment will mean banning many third-party applications from accessing services. Microsoft would immediately be criticized for no longer supporting former customers and promoting the use of their customers. That’s why the life of a publisher is not always very simple.
This basic authentication, which does not support multifactor authentication, will have to live for some time. One of the solutions is, if you can, to detect from your IdP these famous basic mode accesses and inform the user that they have tried to access collaboration services with unauthorized tools and invite them to change their password and then use the appropriate application. Some vendors such as Vmware (https://www.vmware.com/pdf/vidm-office365-saml.pdf) provide solutions for detecting and banning access using basic authentication. Microsoft offers a more integrated solution to their Cloud solution that requires conditional access to the use of an application using modern authentication. Some phone manufacturers have just offered modern authentication as standard like Apple with the new version of IOS 11.
Without adding to the paranoia, there is a risk of piracy on the Office 365 environment. In spite of all the efforts that the American publisher can make in this matter, these will be futile, if you do not even take into account this risk and if you continue to base your access security solely on this pair of login/password. Certain as Deloitte company was taught to their dependency.