MatrixAdapt | Logiciel de gestion d'Entreprise, Création et référencement des sites web

Seo Master present to you: By Steve Marquess, Open Source Software Institute

OpenSSL is perhaps the most widely used of all cryptographic libraries, both in the open source world and by commercial enterprises. The OpenSSL team is often approached by such enterprises seeking assistance with specific problems or features of particular interest to that enterprise. Less often they are approached by a sponsor with a technical need and the vision to address that need in a way that benefits the open source community as a whole.

OSSI has had a long association with OpenSSL, beginning with work over a five year period on the groundbreaking FIPS 140-2 validation of an OpenSSL derived crypto library (implemented largely by Googler Ben Laurie) and continuing with additional validations currently underway with extensive improvements by Dr. Stephen Henson and others. We were pleased to help facilitate Google's sponsorship of RFC4507 support to OpenSSL.

RFC 4507, also known as “stateless session resumption,” is a relatively new draft standard for a mechanism that enables a secure web (TLS) server to resume sessions without explicitly preserving per-client session state. The TLS server encapsulates the session state into a ticket that is preserved in encrypted form and subsequently provided to a client. That client can then resume the previous session using the information in that ticket, avoiding the need for the full TLS negotiation.

This mechanism may be used with any TLS ciphersuite. It makes use of TLS extensions defined in RFC4366 and defines a new TLS message type.

Stateless session resumption is of particular value in the following situations:

1. For servers that handle a large volume of transactions from many users


2. For servers that must cache sessions for a long time


3. For load balancing requests across servers


4. For embedded servers with little memory

As an added bonus, RFC4366 support includes the Server Name Indication extension, which allows browsers to specify a server name when connecting to an SSL host. This means that SSL hosts can finally use name-based virtual hosting instead of burning an IP address per host.

The implementation in OpenSSL and the interoperability testing were performed by Steve Henson. This support is available in both the current 0.9.8 product branch and in the development trunk (0.9.9).2013, By: Seo Master

Seo Master present to you: By Eric Sachs and Ben Laurie, Google Security Team

One of the major conferences on Internet identity standards is the Internet Identity Workshop(IIW), a semiannual 'un-conference' where the sessions are not determined ahead of time. It is attended by a large set of people who work on Internet security and identity standards such as OAuth, OpenID, SAML, InfoCards, etc.  A major theme within the identity community this year has been about improving the user experience and growing the adoption of these technologies. The OpenID community is making great progress on user experience, with Yahoo, AOL, and Google quickly improving the support they provide (read summary from Joseph Smarr of Plaxo). Similarly, the InfoCard community has been working on simplifying the user experience of InfoCard technology, including the updated CardSpace selector from Microsoft.

Another hot topic at IIW centered around how to improve the user experience when testing alternatives and enhancements to passwords to make them less susceptible to phishing attacks. Many websites and enterprises have tried these password enhancements/alternatives, but they found that people complained that they were hard to use, or that they weren't portable enough for people who use multiple computers, including web cafes and smart phones. We have published an article summarizing some of the community's current ideas for how to deploy these new authentication mechanisms using a multi-layered approach that minimizes additional work required by users. We have also pulled together a set of videos showing how a number of these different approaches work with both web-based and desktop applications. We hope this information will be helpful to other websites and enterprises who are concerned about phishing.

[Also posted on the Google Online Security Blog.]2013, By: Seo Master

Seo Master present to you: Do you operate a website and wish you could increase the percentage of users who finish the registration process? As discussed on Google's main blog, Google has been working with Plaxo and Facebook to improve the registration success rate for Gmail users. We now see success rates as high as 90%, compared to the 50-60% rate that most websites see with traditional registration mechanisms. This result was achieved using a combination of our OpenID, OAuth and Portable Contacts APIs. While those APIs have been available for over a year, we have added a number of refinements based on our experience with Plaxo and Facebook. Our documentation now has information on those new features, including:

• OpenID User Interface Extension 1.0 (including the ability to display the favicon of the website)
• x-has-session, which is an enhacement to checkid_immediate requests via the UI extension. If the request includes "openid.ui.x-has-session," it will be echoed in the response only if Google detects an authenticated session
• Support for the US Government's GSA profile for OpenID
• PAPE (Provider Authentication Policy Extension) to support forced password reprompts
• Support for not only Google Accounts, but also our Google Apps customers, as discussed on the Enterprise blog

For more details, please refer to our OpenID documentation.

While these technologies are all standards-based, the methods for how to combine them to achieve this success rate are not obvious, and took a while for the industry to refine. More information is available in the Hybrid Onboarding Guide, but below is a quick summary of some of the best practices for this hybrid onboarding technique:

• The technique is primarily for websites with an existing login system based on email addresses.
• It also assumes the website will send email to users who are not yet registered, whether it is through traditional email marketing or social network invitations.
• The website owner then needs to choose a small set of email providers such as Yahoo and Google that support these standards.
• Whenever the website sends email to a user at one of those providers, any hyperlinks that promote registration at the website should be modified to communicate the email address (or at least domain) of the user back to the website's registration page.
• If the registration page detects a user from one of these domains, it should NOT start the traditional process of asking the user to enter a password, password confirmation, and email. Instead, it should prominently show a single button that says "Sign up with your Google Account" — where Google is replaced with the name of the email provider.
• If the user clicks that button, the website should use the OpenID protocol to ask the email provider to authenticate the user, provide their email address, and optionally ask for access to their address book using the hybrid OpenID/OAuth protocol and the Portable Contacts API. More details about this flow are available on the OpenID blog.
• Once the user returns to the website, it can create an account entry for the user. The website can also mark the email address as verified without having to send a traditional "email verification" link to the user. If the website received the user's permission to access their address book, it can now download it and look for information about the user's friends.
• In the unusual case where an account already exists for that email address, the website can simply log the user into that pre-existing account. 
• For any newly registered user, the website should then display a page that confirms the user is registered and that indicates how they should sign in in the future.
• To make the login process simple, the website should modify their login box to include a logo for each of the trusted email providers it supports, or use one of the other user experiences for Federated Login.
• If a user clicks the email provider button, they can again be sent to that provider's site using the OpenID protocol. When the user comes back, the website can either detect that they previously registered, or if it is a new user, the website can create an account for them on the fly.
• In some cases the account may already exist for that email address, but it was not initially registered using OpenID. In that case, the website can simply log the user in to that pre-existing account.

By Eric Sachs, Product Manager, Google Security2013, By: Seo Master

Seo Master present to you:

Cross-posted from the Google Enterprise Blog

Google Apps is designed to provide a secure and reliable platform for your data. Until today, Google Apps administrators had to sign requests for calls to Google Apps APIs using their username and password (this is called ClientLogin Authorization).

Yet sharing passwords across sites can pose security risks. Furthering our commitment to make the cloud more secure for our users, today we are pleased to announce support for OAuth authorization on Google Apps APIs.

There are several advantages to using OAuth instead of the username/password model:

• OAuth is more secure: OAuth tokens can be scoped and set to expire by a certain date, making them more secure than using the ClientLogin mechanism.
• OAuth is customizable: Using OAuth, you can create tokens that scripts may only use to access data of a particular scope when calling Google Apps APIs. For instance, a token set to call the Email Migration API would not be able to use your login credentials to access the Google Apps Provisioning API.
• OAuth is an open standard: OAuth is an open source standard, making it a familiar choice for developers to work with.

The Google Apps APIs that support the OAuth signing mechanism are:

1. Provisioning API
2. Email Migration API
3. Admin Settings API
4. Calendar Resource API
5. Email Settings API
6. Audit API

OAuth support for Google Apps APIs is another step towards making Google Apps the most secure, reliable cloud based computing environment for organizations. To learn more about OAuth support and other administrative capacities launched in Google Apps this quarter, join us for a live webinar on Wednesday, September 29th at 9am PT / 12pm EST / 5pm GMT.

Administrators for Google Apps Premier, Education, and Government Editions can use OAuth authorization for Google Apps APIs starting today.For more information about the OAuth standard, visit http://oauth.net.

By Ankur Jain, Google Apps Team2013, By: Seo Master