Création des Logiciels de gestion d'Entreprise, Création et référencement des sites web, Réseaux et Maintenance, Conception
seo Keeping OpenSSL up-to-date 2013
Seo Master present to you:
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:
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
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:
- For servers that handle a large volume of transactions from many users
- For servers that must cache sessions for a long time
- For load balancing requests across servers
- 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 User Experience in the Identity Community 2013
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
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 Hybrid Onboarding 2013
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:
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:
2013, By: Seo Master
- 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.
2013, By: Seo Master
seo New OAuth support for Google Apps APIs 2013
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:
- Provisioning API
- Email Migration API
- Admin Settings API
- Calendar Resource API
- Email Settings API
- 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.
2013, By: Seo Masterseo Usability Research on Federated Login 2013
Seo Master present to you: By Eric Sachs, Product Manager, Google Security
Federated login has been a goal of the Internet community for a long time, but its usage is still quite low, especially in the consumer space. This has led to the constant need for users to create yet another account to log in to a new website, and most consumers use the same password across websites even though they realize this is a poor security practice. In the enterprise space, many software-as-a-service vendors such as Salesforce.com and Google Apps for Your Domain do support federated login, but even those vendors encounter usability problems.
On September 12 the OpenID Foundation held a meeting to gather feedback on how to evolve the best practices for using OpenID so that it might be used by websites in a larger number of market segments. The meeting included representatives from many mainstream websites including The New York Times, BBC, AARP, Time Inc., and NPR. Google has been researching federated login techniques, and at the meeting we showed how a traditional login box might evolve (see below) to a new style of login box that better supports federated login.
We also shared a summary of our usability research that explains how this helps a website add support for federated login for some users without hurting usability for the rest of the website's user base. We hope that industry groups, such as this committee in the OpenID Foundation, will continue to share ideas and experiences so we can develop a model for federated login that can be broadly deployed by websites and broadly used by consumers. If your company has experience or research that you can share, we hope you will get involved with the OpenID community and join the further discussions on this topic.2013, By: Seo Master
Federated login has been a goal of the Internet community for a long time, but its usage is still quite low, especially in the consumer space. This has led to the constant need for users to create yet another account to log in to a new website, and most consumers use the same password across websites even though they realize this is a poor security practice. In the enterprise space, many software-as-a-service vendors such as Salesforce.com and Google Apps for Your Domain do support federated login, but even those vendors encounter usability problems.
On September 12 the OpenID Foundation held a meeting to gather feedback on how to evolve the best practices for using OpenID so that it might be used by websites in a larger number of market segments. The meeting included representatives from many mainstream websites including The New York Times, BBC, AARP, Time Inc., and NPR. Google has been researching federated login techniques, and at the meeting we showed how a traditional login box might evolve (see below) to a new style of login box that better supports federated login.
We also shared a summary of our usability research that explains how this helps a website add support for federated login for some users without hurting usability for the rest of the website's user base. We hope that industry groups, such as this committee in the OpenID Foundation, will continue to share ideas and experiences so we can develop a model for federated login that can be broadly deployed by websites and broadly used by consumers. If your company has experience or research that you can share, we hope you will get involved with the OpenID community and join the further discussions on this topic.2013, By: Seo Master
seo Adding OAuth 2.0 support for IMAP/SMTP and XMPP to enhance auth security 2013
Seo Master present to you: 
By Ryan Troll, Application Security Team
Cross-posted with the Google Online Security Blog
Our users and developers take password security seriously and so do we. Passwords alone have weaknesses we all know about, so we’re working over the long term to support additional mechanisms to help protect user information. Over a year ago, we announced a recommendation that OAuth 2.0 become the standard authentication mechanism for our APIs so you can make the safest apps using Google platforms. You can use OAuth 2.0 to build clients and websites that securely access account data and work with our advanced security features, such as 2-step verification. But our commitment to OAuth 2.0 is not limited to web APIs. Today we’re going a step further by adding OAuth 2.0 support for IMAP/SMTP and XMPP. Developers using these protocols can now move to OAuth 2.0, and users will experience the benefits of more secure OAuth 2.0 clients.
When clients use OAuth 2.0, they never ask users for passwords. Users have tighter control over what data clients have access to, and clients never see a user's password, making it much harder for a password to be stolen. If a user has their laptop stolen, or has any reason to believe that a client has been compromised, they can revoke the client’s access without impacting anything else that has access to their data.
We are also announcing the deprecation of older authentication mechanisms. If you’re using these you should move to the new OAuth 2.0 APIs.
Ryan Troll has been with Google since 2010, and now works with the Application Security Team, focusing on OAuth and 2-Step Verification. When not at work, he spends time with his family, reads, and occasionally plays poker.
Posted by Scott Knaster, Editor
2013, By: Seo Master
By Ryan Troll, Application Security TeamCross-posted with the Google Online Security Blog
Our users and developers take password security seriously and so do we. Passwords alone have weaknesses we all know about, so we’re working over the long term to support additional mechanisms to help protect user information. Over a year ago, we announced a recommendation that OAuth 2.0 become the standard authentication mechanism for our APIs so you can make the safest apps using Google platforms. You can use OAuth 2.0 to build clients and websites that securely access account data and work with our advanced security features, such as 2-step verification. But our commitment to OAuth 2.0 is not limited to web APIs. Today we’re going a step further by adding OAuth 2.0 support for IMAP/SMTP and XMPP. Developers using these protocols can now move to OAuth 2.0, and users will experience the benefits of more secure OAuth 2.0 clients.
When clients use OAuth 2.0, they never ask users for passwords. Users have tighter control over what data clients have access to, and clients never see a user's password, making it much harder for a password to be stolen. If a user has their laptop stolen, or has any reason to believe that a client has been compromised, they can revoke the client’s access without impacting anything else that has access to their data.
We are also announcing the deprecation of older authentication mechanisms. If you’re using these you should move to the new OAuth 2.0 APIs.
- We are deprecating XOAUTH for IMAP/SMTP, as it uses OAuth 1.0a, which was previously deprecated. Gmail will continue to support XOAUTH until OAuth 1.0a is shut down, at which time support will be discontinued.
- We are also deprecating X-GOOGLE-TOKEN and SASL PLAIN for XMPP, as they either accept passwords or rely on the previously deprecated ClientLogin. These mechanisms will continue to be supported until ClientLogin is shut down, at which time support for both will be discontinued.
Ryan Troll has been with Google since 2010, and now works with the Application Security Team, focusing on OAuth and 2-Step Verification. When not at work, he spends time with his family, reads, and occasionally plays poker.
Posted by Scott Knaster, Editor
2013, By: Seo Master
seo Native Client Security Contest: The results are in! 2013
Seo Master present to you: A few months ago, we challenged you to discover exploits in the Native Client system and more than 600 of you decided to take us up on our invitation. We're very pleased with the results: participants found bugs that enabled some really clever exploits, but nothing that pointed to a fundamental flaw in the design of Native Client. Our judges reviewed all entries very carefully and have selected five teams as the winners of the Native Client Security Contest.
The big winner of the contest was the team "Beached As", consisting of IBM researcher Mark Dowd and independent researcher Ben Hawkes. "Beached As" reported 12 valid issues, including vulnerabilities in the validator and multiple type-confusion attacks. The team "CJETM" (Chris Rohlf, Jason Carpenter, Eric Monti — all security professionals with Matasano Security) came in second by reporting three issues with a common theme of memory related defects, including an uninitialized vtable entry, an exception condition during new(), and a double delete bug. Gabriel Campana from Sogeti ESEC R&D Labs was selected as the third place, while for the fourth and fifth place we had a tie between independent researcher Daiki Fukumori and Rensselaer Polytechnic Institute student Alex Radocea. You can find a listing of all the issues the teams submitted at the Native Client Security Contest site.
The winners of the Native Client Security Contest, Team "Beached As"
Mark Dowd (left) and Ben Hawkes (right)
Winning teams were attracted to the contest by the potential of the Native Client technology. Mark Dowd, member of the winning team "Beached As", commented, "When I saw the press release announcing the product, I was intrigued by some of the ideas mentioned in the article. After reviewing the architecture a little, I thought the project adopted a novel approach to solving the problem of running native code securely, and was keen to take a closer look." Curiosity about what the technology could achieve also motivated the CJETM team, according to Chris Rohlf.
The real-world relevance of Native Client made this contest more interesting and challenging for participants. Contestant Alex Radocea stated, "Unlike most security challenges out there, the set of problems were not crafted. The tasks at hand were real and complex, as the real world is. I have no doubt that many unknown people eyed the code or attacked the applications and, frustratingly, found absolutely nothing wrong." Mark Dowd agreed: "Our goal was to create a convincing lead, to try and take the victory, and I think we did that. Having said that, the field was not soft. There were some tough contestants who were able to uncover a variety of interesting vulnerabilities."
We would like to thank all the contestants, the jury chair Ed Felten and all the security experts that judged the contest for helping us improve the security of our system. This contest helped us discover implementation errors in Native Client and some areas of our codebase we need to spend more time reviewing. More importantly, that no major architectural flaws were found provides evidence that Native Client can be made safe enough for widespread use. Toward that end, we're implementing additional security measures, such as an outer sandbox, but you can help by continuing to file bugs in Native Client. Community support and scrutiny has helped and will continue to help make Native Client more useful and more secure.
2013, By: Seo Master
The big winner of the contest was the team "Beached As", consisting of IBM researcher Mark Dowd and independent researcher Ben Hawkes. "Beached As" reported 12 valid issues, including vulnerabilities in the validator and multiple type-confusion attacks. The team "CJETM" (Chris Rohlf, Jason Carpenter, Eric Monti — all security professionals with Matasano Security) came in second by reporting three issues with a common theme of memory related defects, including an uninitialized vtable entry, an exception condition during new(), and a double delete bug. Gabriel Campana from Sogeti ESEC R&D Labs was selected as the third place, while for the fourth and fifth place we had a tie between independent researcher Daiki Fukumori and Rensselaer Polytechnic Institute student Alex Radocea. You can find a listing of all the issues the teams submitted at the Native Client Security Contest site.
The winners of the Native Client Security Contest, Team "Beached As"
Mark Dowd (left) and Ben Hawkes (right)
Winning teams were attracted to the contest by the potential of the Native Client technology. Mark Dowd, member of the winning team "Beached As", commented, "When I saw the press release announcing the product, I was intrigued by some of the ideas mentioned in the article. After reviewing the architecture a little, I thought the project adopted a novel approach to solving the problem of running native code securely, and was keen to take a closer look." Curiosity about what the technology could achieve also motivated the CJETM team, according to Chris Rohlf.
The real-world relevance of Native Client made this contest more interesting and challenging for participants. Contestant Alex Radocea stated, "Unlike most security challenges out there, the set of problems were not crafted. The tasks at hand were real and complex, as the real world is. I have no doubt that many unknown people eyed the code or attacked the applications and, frustratingly, found absolutely nothing wrong." Mark Dowd agreed: "Our goal was to create a convincing lead, to try and take the victory, and I think we did that. Having said that, the field was not soft. There were some tough contestants who were able to uncover a variety of interesting vulnerabilities."
We would like to thank all the contestants, the jury chair Ed Felten and all the security experts that judged the contest for helping us improve the security of our system. This contest helped us discover implementation errors in Native Client and some areas of our codebase we need to spend more time reviewing. More importantly, that no major architectural flaws were found provides evidence that Native Client can be made safe enough for widespread use. Toward that end, we're implementing additional security measures, such as an outer sandbox, but you can help by continuing to file bugs in Native Client. Community support and scrutiny has helped and will continue to help make Native Client more useful and more secure.2013, By: Seo Master
seo The results are in: Hardcode, the secure coding contest for App Engine 2013
Seo Master present to you: 
By Eduardo Vela Nava, Security Team
This January, Google and SyScan announced a secure coding competition open to students from all over the world. While Google’s Summer of Code and Code-in encourage students to contribute to open source projects, Hardcode was a call for students who wanted to showcase their skills both in software development and security. Given the scope of today’s online threats, we think it’s incredibly important to practice secure coding habits early on. Hundreds of students from 25 countries and across five continents signed up to receive information about the competition, and over 100 teams participated.
During the preliminary online round, teams built applications on Google App Engine that were judged for both functionality and security. Five teams were then selected to participate in the final round at the SyScan 2013 security conference in Singapore, where they had to do the following: fix security bugs from the preliminary round, collaborate to develop an API standard to allow their applications to interoperate, implement the API, and finally, try to hack each other’s applications. To add to the challenge, many of the students balanced the competition with all of their school commitments.
We’re extremely impressed with the caliber of the contestants’ work. Everyone had a lot of fun, and we think these students have a bright future ahead of them. We are pleased to announce the final results of the 2013 Hardcode Competition:
1st Place: Team 0xC0DEBA5E
Vienna University of Technology, Austria (SGD $20,000)
2nd Place: Team Gridlock
Loyola School, Jamshedpur, India (SGD $15,000)
3rd Place: Team CeciliaSec
University of California, Santa Barbara, California, USA (SGD $10,000)
Runner-up: Team AppDaptor
The Hong Kong Polytechnic University, Hong Kong (SGD $5,000)
Runner-up: Team DesiCoders
Birla Institute of Technology & Science, Pilani, India (SGD $5,000)
Honorable Mention: Team Saviors of Middle Earth (withdrew due to school commitments)
Walt Whitman High School, Maryland, USA
A big congratulations to this very talented group of students!
Eduardo Vela Nava is a Tech Lead for Google's WOOPS (Web or Other Product Security) team, helping teams build safer products.
Posted by Scott Knaster, Editor
2013, By: Seo Master
By Eduardo Vela Nava, Security Team
This January, Google and SyScan announced a secure coding competition open to students from all over the world. While Google’s Summer of Code and Code-in encourage students to contribute to open source projects, Hardcode was a call for students who wanted to showcase their skills both in software development and security. Given the scope of today’s online threats, we think it’s incredibly important to practice secure coding habits early on. Hundreds of students from 25 countries and across five continents signed up to receive information about the competition, and over 100 teams participated.
During the preliminary online round, teams built applications on Google App Engine that were judged for both functionality and security. Five teams were then selected to participate in the final round at the SyScan 2013 security conference in Singapore, where they had to do the following: fix security bugs from the preliminary round, collaborate to develop an API standard to allow their applications to interoperate, implement the API, and finally, try to hack each other’s applications. To add to the challenge, many of the students balanced the competition with all of their school commitments.
We’re extremely impressed with the caliber of the contestants’ work. Everyone had a lot of fun, and we think these students have a bright future ahead of them. We are pleased to announce the final results of the 2013 Hardcode Competition:
1st Place: Team 0xC0DEBA5E
Vienna University of Technology, Austria (SGD $20,000)
- Daniel Marth
- Lukas Pfeifhofer
- Benedikt Wedenik
2nd Place: Team Gridlock
Loyola School, Jamshedpur, India (SGD $15,000)
3rd Place: Team CeciliaSec
University of California, Santa Barbara, California, USA (SGD $10,000)
- Nathan Crandall
- Dane Pitkin
- Justin Rushing
Runner-up: Team AppDaptor
The Hong Kong Polytechnic University, Hong Kong (SGD $5,000)
Runner-up: Team DesiCoders
Birla Institute of Technology & Science, Pilani, India (SGD $5,000)
- Yash Agarwal
- Vishesh Singhal
Honorable Mention: Team Saviors of Middle Earth (withdrew due to school commitments)
Walt Whitman High School, Maryland, USA
- Wes Kendrick
- Marc Rosen
- William Zhang
A big congratulations to this very talented group of students!
Eduardo Vela Nava is a Tech Lead for Google's WOOPS (Web or Other Product Security) team, helping teams build safer products.
Posted by Scott Knaster, Editor
2013, By: Seo Master
seo Security advisory to websites using OpenID Attribute Exchange 2013
Seo Master present to you: 
By Mayank Upadhyay, Google Security Team
A group of security researchers recently identified a flaw in how some OpenID relying parties implement Attribute Exchange (AX) that could cause an authentication bypass vulnerability. Google is a strong supporter of federated login on the web and would like to help spread awareness of this issue to websites that are OpenID relying parties in order to protect the users of those websites. This issue primarily impacts websites that act as relying parties using the OpenID4Java library.
The researchers determined that the affected sites were not confirming that certain information passed through AX was properly signed. If the site was only using AX to receive information like the user’s self-asserted gender, then this issue would be minor. However, if it was being used to receive security-sensitive information that only the identity provider should assert, then the consequences could be worse.
A specific scenario identified involves a website that accepts an unsigned AX attribute for email address, and then logs the user in to a local account on that website associated with the email address. When a website asks Google’s OpenID provider (IDP) for someone’s email address, we always sign it in a way that cannot be replaced by an attacker. However, many websites do not ask for email addresses for privacy reasons among others, and so it is a perfectly legitimate response for the IDP to not include this attribute by default. An attacker could forge an OpenID request that doesn’t ask for the user’s email address, and then insert an unsigned email address into the IDPs response. If the attacker relays this response to a website that doesn’t notice that this attribute is unsigned, the website may be tricked into logging the attacker in to any local account.
The researchers contacted the primary websites they identified with this vulnerability, and those sites have already deployed a fix. Similarly, Google and other OpenID Foundation members have worked to identify many other websites that were impacted and have helped them deploy a fix. There are no known cases of this attack being exploited at this point in time.
A detailed explanation of the use of claimed IDs and email addresses can be found in Google’s OpenID best practices.
Google would like to thank security researchers Rui Wang, Shuo Chen and XiaoFeng Wang for reporting their findings. The OpenID Foundation has also done a similar blog post on the issue.
Action Required:
Suggested Fix:
As a first step, we recommend modifying vulnerable relying parties to accept AX attribute values only when signed, irrespective of how those attributes might get used.
During our investigation we confirmed that apps using the OpenID4Java library, with or without the Step2 wrapper, are prone to accepting unsigned AX attributes. OpenID4Java has been patched with the fix in version 0.9.6.662 (19th April, 2011).
Kay Framework was known to be vulnerable and has since been patched. Users should upgrade to version 1.0.2 or later. Note that Google App Engine developers that use its built-in OpenID support do not need to do anything.
Other libraries may have the same issue, although we do not believe that the default usage of OpenID services and libraries from Janrain, Ping Identity and DotNetOpenAuth are susceptible to this attack. However, the defaults may be overridden and you should double check your code for that.
We also suggest reviewing your usage of email addresses retrieved via OpenID to ensure that adequate safeguards are in place. A detailed explanation of the use of claimed IDs and email addresses can be found in our OpenID best practices published for Apps Marketplace developers that also apply to relying parties in general.
Mayank Upadhyay works on authentication and identity problems on the Google Security Team.
His previous experience includes similar work at Sun Microsystems and various companies in the WiFi security space.
Posted by Scott Knaster, Editor
2013, By: Seo Master
By Mayank Upadhyay, Google Security Team
A group of security researchers recently identified a flaw in how some OpenID relying parties implement Attribute Exchange (AX) that could cause an authentication bypass vulnerability. Google is a strong supporter of federated login on the web and would like to help spread awareness of this issue to websites that are OpenID relying parties in order to protect the users of those websites. This issue primarily impacts websites that act as relying parties using the OpenID4Java library.
The researchers determined that the affected sites were not confirming that certain information passed through AX was properly signed. If the site was only using AX to receive information like the user’s self-asserted gender, then this issue would be minor. However, if it was being used to receive security-sensitive information that only the identity provider should assert, then the consequences could be worse.
A specific scenario identified involves a website that accepts an unsigned AX attribute for email address, and then logs the user in to a local account on that website associated with the email address. When a website asks Google’s OpenID provider (IDP) for someone’s email address, we always sign it in a way that cannot be replaced by an attacker. However, many websites do not ask for email addresses for privacy reasons among others, and so it is a perfectly legitimate response for the IDP to not include this attribute by default. An attacker could forge an OpenID request that doesn’t ask for the user’s email address, and then insert an unsigned email address into the IDPs response. If the attacker relays this response to a website that doesn’t notice that this attribute is unsigned, the website may be tricked into logging the attacker in to any local account.
The researchers contacted the primary websites they identified with this vulnerability, and those sites have already deployed a fix. Similarly, Google and other OpenID Foundation members have worked to identify many other websites that were impacted and have helped them deploy a fix. There are no known cases of this attack being exploited at this point in time.
A detailed explanation of the use of claimed IDs and email addresses can be found in Google’s OpenID best practices.
Google would like to thank security researchers Rui Wang, Shuo Chen and XiaoFeng Wang for reporting their findings. The OpenID Foundation has also done a similar blog post on the issue.
Action Required:
- If you are an OpenID relying party, then you should read the Suggested Fix section below to see if this vulnerability might apply to you, and what to do about it.
- If you are an application developer that uses OpenID relying party services from someone else, like your container provider or some network intermediary, please read the Suggested Fix section to see if your service is listed there. Otherwise, you should check with that entity to make sure they are not susceptible to this issue.
Suggested Fix:
As a first step, we recommend modifying vulnerable relying parties to accept AX attribute values only when signed, irrespective of how those attributes might get used.
During our investigation we confirmed that apps using the OpenID4Java library, with or without the Step2 wrapper, are prone to accepting unsigned AX attributes. OpenID4Java has been patched with the fix in version 0.9.6.662 (19th April, 2011).
Kay Framework was known to be vulnerable and has since been patched. Users should upgrade to version 1.0.2 or later. Note that Google App Engine developers that use its built-in OpenID support do not need to do anything.
Other libraries may have the same issue, although we do not believe that the default usage of OpenID services and libraries from Janrain, Ping Identity and DotNetOpenAuth are susceptible to this attack. However, the defaults may be overridden and you should double check your code for that.
We also suggest reviewing your usage of email addresses retrieved via OpenID to ensure that adequate safeguards are in place. A detailed explanation of the use of claimed IDs and email addresses can be found in our OpenID best practices published for Apps Marketplace developers that also apply to relying parties in general.
Mayank Upadhyay works on authentication and identity problems on the Google Security Team.
His previous experience includes similar work at Sun Microsystems and various companies in the WiFi security space.
Posted by Scott Knaster, Editor
2013, By: Seo Master
seo Best Practices for User Authentication 2013
Seo Master present to you: By now, many of you have seen our recent announcement regarding 2-step verification for Google Accounts. It’s an optional way of protecting your Google Account from unauthorized access, providing a level of security beyond that of a password alone. The initial announcement did not detail the impact enabling 2-step verification has on programmatic account access from code written against one of Google’s official APIs. We want to go into some more detail regarding the implications of 2-step verification on various authentication (and authorization) techniques, and offer best practices that you as a developer should follow.
There are three forms of authentication supported by almost all of Google’s APIs. AuthSub and OAuth (either version 1 or the newer OAuth 2) are similar web-based authentication mechanisms in which the user logs in on a web page hosted by Google. The other approach to authentication, ClientLogin, relies on your application soliciting the user’s account address and password, and then sending that information to Google.
If your code uses AuthSub or OAuth, then you don’t have to do anything special to accommodate users who have opted-in to 2-step verification. The web-based login flow currently allows users to enter both their normal passwords as well as the additional verification code, and this extra step is transparent to you as the developer.
ClientLogin, however, does not fare as well for accounts that have 2-step verification enabled. There is no concept of an additional verification code in the ClientLogin process, and a user’s account address and password are no longer sufficient for authenticating them once 2-step verification is turned on. If you make a ClientLogin authentication request for such an account, you’ll get back an
There are two solutions to these failed ClientLogin attempts. The first solution, which does not require changing any existing code, is to ask your users to generate an application-specific password and to provide that, instead of their Google Account passwords, when making your ClientLogin request. You can point your users to this article for a full explanation of how application-specific passwords work.
The second, and recommended, solution requires some work on your part as a developer: moving away from ClientLogin completely, in favor of OAuth 2. If your code runs as part of a web application, then OAuth 2’s web-based login flow is trivial to integrate. Even applications that are installed on a user’s computer or other device can leverage OAuth 2, though. This guide explains how to launch a web browser to handle the login process, and then redirect control back to your application.
While it may take some effort to migrate your code away from ClientLogin, your users will be grateful that you did. Even those who haven’t enabled 2-step verification will benefit from entering their credentials on a web page accessed via HTTPS and hosted by Google, as opposed to sharing their password information directly with your third party code.
2013, By: Seo Master
There are three forms of authentication supported by almost all of Google’s APIs. AuthSub and OAuth (either version 1 or the newer OAuth 2) are similar web-based authentication mechanisms in which the user logs in on a web page hosted by Google. The other approach to authentication, ClientLogin, relies on your application soliciting the user’s account address and password, and then sending that information to Google.
If your code uses AuthSub or OAuth, then you don’t have to do anything special to accommodate users who have opted-in to 2-step verification. The web-based login flow currently allows users to enter both their normal passwords as well as the additional verification code, and this extra step is transparent to you as the developer.
ClientLogin, however, does not fare as well for accounts that have 2-step verification enabled. There is no concept of an additional verification code in the ClientLogin process, and a user’s account address and password are no longer sufficient for authenticating them once 2-step verification is turned on. If you make a ClientLogin authentication request for such an account, you’ll get back an
HTTP 403 error response from our servers with the following in error included in the response body:
Error=BadAuthentication
Info=InvalidSecondFactor
There are two solutions to these failed ClientLogin attempts. The first solution, which does not require changing any existing code, is to ask your users to generate an application-specific password and to provide that, instead of their Google Account passwords, when making your ClientLogin request. You can point your users to this article for a full explanation of how application-specific passwords work.
The second, and recommended, solution requires some work on your part as a developer: moving away from ClientLogin completely, in favor of OAuth 2. If your code runs as part of a web application, then OAuth 2’s web-based login flow is trivial to integrate. Even applications that are installed on a user’s computer or other device can leverage OAuth 2, though. This guide explains how to launch a web browser to handle the login process, and then redirect control back to your application.
While it may take some effort to migrate your code away from ClientLogin, your users will be grateful that you did. Even those who haven’t enabled 2-step verification will benefit from entering their credentials on a web page accessed via HTTPS and hosted by Google, as opposed to sharing their password information directly with your third party code.
2013, By: Seo Master
seo Improving the security of Google APIs with SSL 2013
Seo Master present to you: We at Google go to great lengths to ensure every step is taken to protect our users’ data. As part of our ongoing effort to improve security everywhere, we will start requiring the use of SSL in many products. Requiring SSL improves security by encrypting data communications between users and Google, better protecting it from being intercepted by a malicious third party.
Some of these changes have already occurred. Many user-facing Google products now allow or require SSL, including encrypting Google web search, defaulting to SSL in Gmail, and requiring SSL in Google Docs. Next on our list is to improve SSL support for our developer facing APIs. For most APIs, our technical documentation, client libraries and code samples already use SSL. Many new APIs and versions will be SSL only. Further, the Google Maps API, which previously offered SSL only to Premier customers, is offering SSL to all developers starting today.
Additionally, beginning September 15, 2011, Google will require that all users of Google Documents List API, Google Spreadsheets API, and Google Sites API use SSL connections for all API requests. Specifically, this change will disallow all HTTP requests, responding with an HTTP 400 Bad Request response. API requests will only be accepted via HTTPS. For example, a request to http://docs.google.com/feeds/default/private/full will no longer pull a list of a user's documents. Instead, a request must be made to https://docs.google.com/feeds/default/private/full.
This change should be transparent if you're using the most recent version of the Google Data client libraries, since they already use SSL for all requests. If you're not using the latest version, then please upgrade as soon as possible. If you're not using our client libraries, then simply change any use of an HTTP URL to its corresponding HTTPS version in your code. Your existing OAuth and AuthSub tokens will continue to work using the HTTPS URLs, even if they were requested with a scope that uses an ‘http://’ scheme.
Although we’re initially requiring SSL for only a few APIs (those whose traffic was already mostly over SSL), we strongly recommend that you convert all your API clients as soon as possible to help protect your users’ data. Check the documentation for each API for more information about that API's SSL support, including the updated Google Documents List API documentation, Google Spreadsheets API documentation, and Google Sites API documentation.
If you have any questions or concerns about this change, please follow up in the forums of the API you are using.
2013, By: Seo Master
Some of these changes have already occurred. Many user-facing Google products now allow or require SSL, including encrypting Google web search, defaulting to SSL in Gmail, and requiring SSL in Google Docs. Next on our list is to improve SSL support for our developer facing APIs. For most APIs, our technical documentation, client libraries and code samples already use SSL. Many new APIs and versions will be SSL only. Further, the Google Maps API, which previously offered SSL only to Premier customers, is offering SSL to all developers starting today.
Additionally, beginning September 15, 2011, Google will require that all users of Google Documents List API, Google Spreadsheets API, and Google Sites API use SSL connections for all API requests. Specifically, this change will disallow all HTTP requests, responding with an HTTP 400 Bad Request response. API requests will only be accepted via HTTPS. For example, a request to http://docs.google.com/feeds/default/private/full will no longer pull a list of a user's documents. Instead, a request must be made to https://docs.google.com/feeds/default/private/full.
This change should be transparent if you're using the most recent version of the Google Data client libraries, since they already use SSL for all requests. If you're not using the latest version, then please upgrade as soon as possible. If you're not using our client libraries, then simply change any use of an HTTP URL to its corresponding HTTPS version in your code. Your existing OAuth and AuthSub tokens will continue to work using the HTTPS URLs, even if they were requested with a scope that uses an ‘http://’ scheme.
Although we’re initially requiring SSL for only a few APIs (those whose traffic was already mostly over SSL), we strongly recommend that you convert all your API clients as soon as possible to help protect your users’ data. Check the documentation for each API for more information about that API's SSL support, including the updated Google Documents List API documentation, Google Spreadsheets API documentation, and Google Sites API documentation.
If you have any questions or concerns about this change, please follow up in the forums of the API you are using.
2013, By: Seo Master