After the success of last year's GSOC project with Drupal, I thought it would be a great idea to see if we could take what we did there (server-side encryption) and do something similar on the client side. The benefit of this approach is that unencrypted content/data is never seen by the hosting server. So it's not necessary to trust it to the same degree.
The problem with most encryption strategies nowadays is that they require third-party software and/or services, require maintenance of additional keys and/or secrets, and provide an awful user experience.
I recently had a client that began delegating access to all of its data assets across the enterprise network via OAuth, specifically the OAuth 2.0 protocol. While I was there architecting a Drupal solution as their new Web platform, they wanted me to to hook into this system to authenticate their Drupal users. Although there have been some modules available in the ecosystem to support OAuth2, there weren't any available to provide this functionality. So I created the OAuth2 Authentication module.
On October 15th, 2014, the highly critical SA-CORE-2014-005 - Drupal core - SQL injection vulnerability was announced. Shortly afterwards, research showed that sites not patched that same day could very well be compromised. Two weeks later, a public service announcement was released explaining the gravity of the situation. There was also a FAQ, a flowchart for dealing with it and a module that could potentially confirm a compromised site. Needless to say, it was a challenging time for the community.
Services like LastPass are extremely popular for automatically entering credentials (username and password combinations) for logging into Web sites. They also generate passwords as needed and store them. They're not without their problems, however.
The two major issue with these types of services are the following:
