Today is National Buttermilk Biscuit Day. Biscuits fill me with joy, as do community integrations, so here's a post packed with deliciousness from amazing people in the Stormpath community. (First, here's an awesome biscuit recipe. Happy Biscuit Day!)

• CAS-Addons, now with Richer Stormpath Support
• Python Login Skeleton for Stormpath

High profile database breaches aren’t a daily thing just yet, but they’re certainly not rare. Linode’s recent system-wide password reset and Scribd's account compromises were announced just nine days apart. In the last week, there have been breaches at LivingSocial and Reputation.com. Pay attention to the e-mails sent after hacks like these, and you’ll notice they often come with a set of new password recommendations. Password best practices are something Stormpath has already covered in depth, but always from a backend perspective.

So, instead of cautioning against hashing with MD5 again (seriously though, don’t do it), we wanted to take a look at some of the more insidious password myths we run into. We hope this helps developers create smart password policies, which we will shamelessly mention you can set automatically if you use Stormpath.

...or How To Report Password Attacks

Reputation.com just reported a security breach to users, with the email below. There are some great takeaways here for reporting breaches to your users:

• Be specific and explicit about what data is compromised - I think the bullet point list is great. More companies should be this straightforward.
• Get on it immediately - their users heard about this before the media did. 
• Offer an incentive - a year of credit reporting is a nice thing when your personal data has been compromised.
• Immediately change the password of every user affected - users are fallable and don't check their email every minute so it's better not to wait on them.
• "Only the jurisdiction of North Dakota requires us to disclose information about this incident. However, out of an abundance of caution..." Yes. Reputation.com's contract is with the user, not with the state. Following the "letter of the law" in a password breach underserves your userbase. Legislation around data privacy is spotty. By going beyond the required transparency and contacting everyone, the company not only protected themselves, but started on the path of rebuilding trust with their users. (That said, pointing out to users that you don't have to tell them when you've been breached might not make you any friends).

A few things they could have done differently:

Create, Update and HTTP Idempotence

For developers building REST-based APIs, there is a great deal of misinformation and some understandable confusion about when to use HTTP PUT and when to use HTTP POST. Some say, POST should be used to create a resource, and PUT to modify one. Others that PUT should be used to create, and POST to modify one. Neither is quite right.

Often, developers think of each HTTP method as a 1:1 relationship with CRUD operations:

CRUD       HTTP
Create      POST
Read         GET
Update     PUT
Delete      DELETE

This can be true, with GET and DELETE specifically, but when it comes to which HTTP methods should be associated with create and update, the answer comes down to idempotency.

When we launched Alpha testing for Stormpath last year, there was a worthy debate about what would be the best signup flow. We wanted to ensure potential attackers wouldn’t be able to create dummy accounts and that we would be able to contact users reliably, but we also wanted an easy user experience. Signup workflows are fickle, hotly contested, and can present a security hole if you do them wrong, and we eat our own dog food and register users to Stormpath… using Stormpath. Figuring out signup best practices is important both for us and for our customers.

A few months ago, we upgraded the signup workflow. Despite asking for more information,the upgraded workflow increased our signup completion from 74% to 94%. Instantly. All we did was change the order of the four-step process.

We already showed you how to build a Beautiful REST+JSON API, but how do you secure your API?  At Stormpath we spent 18 months researching best practices, implementing them in the Stormpath API, and figuring out what works. Here’s our playbook on how to secure a REST API.

Choose the Right Security Protocol

Industry standard authentication protocols help reduce the effort of securing your API. Custom security protocols can be used, but only under very specific circumstances.  Here is a brief overview of the benefits and drawbacks of the top protocols.

Last year Microsoft Research posted a great paper^[1] on passwords in an attempt to answer the question, “After 40 years of security research, why is the password still dominant?” Surprisingly, most security people haven’t read it. Not hard to guess why—it’s a dense 15-page academic paper titled “The Quest to Replace Passwords: A Framework for Comparative Evaluation of Web Authentication Schemes.” We’ve decided to post a summary of the paper, with some of our own thoughts, for the betterment of security for all.

The goal of the researchers was to provide a framework for evaluating alternative authentication methods like multi-factor, biometrics, and federated SSO. Some of the options they reviewed are wildly impractical for most customer facing web applications (i.e., paper-based one time passwords) but overall the framework is very useful. After 40 years of security research, passwords still doggedly persist as the de facto standard for application authentication. Why? Because while there are more secure alternatives, like multi-factor authentication, nothing comes close to passwords when you account for usability and ease of deployment.

Stormpath landed at PyCon last week with a shiny new Python SDK and five team members looking for Pythonista feedback. After our action-packed February, expectations for the conference were high—and the Python community did not disappoint! Thousands of attendees gathered in Santa Clara to learn and collaborate in an atmosphere that had our team excited to be a part of the buzz.

Not coincidentally, this was a pretty fantastic time to launch our official support for Python. And judging by the number of requests we’ve been receiving from Pythonistas lately, we were just in time.

Last week, amid the hoopla of our fundraising announcement, we ended Private Beta and released major enhancements to the API. Many of these came from user feedback.**

In the coming months, we will be building out the SDKs and sample apps to make it easier to connect to the Stormpath API. Of course, there are many features left to build, so anyone can now submit a feature request on our knowledge base or add stories to a request. 

Here's a sample of what was in last week's release:

Today we announced $8.2M in Series A financing.  It’s a big achievement for our team and a huge commitment to our vision and customers.  Most importantly, it’s fuel: fuel to recruit the best people, fuel to build a revolutionary security product, and fuel to empower thousands of developers with the Stormpath API.

What Is Stormpath?

Stormpath is the first easy and secure user management and authentication service for developers.  Our API handles authentication, password storage, user management, access control, and common security workflows like password reset.

In a nutshell, it’s all the user security an application needs, but developers really don’t want to build. 

The Storm Is Rising

We believe Stormpath is a revolutionary and disruptive product, but more importantly, we believe the rising tide of developer services is changing software development. Today, for the first time ever, an SMB operating in the cloud has access to more advanced technology than a Fortune 100 competitor stuck in a data center.