How *Not* To Implement A Web Application That Handles External Authentication, Using BeTwittered.com As An Example
Today I'm going to look at how not to handle user authentication in a web application, taking BeTwittered.com authenticating with Twitter as an example (sorry, guys).
BeTwittered is a simple and comfortable gadget that you can add to your site, such as your iGoogle homepage.
Since BeTwittered is just a bridge between you and Twitter, it has to first log you into your account. Here is where things go horribly, horribly wrong.
1. BeTwittered does not use SSL to secure requests to its servers
All authentication information is transmitted to BeTwittered servers in plain text and is easily sniffable by an attacker, both on your own network and outside of it. You can read more about SSL encryption here….
OK, maybe you did know them – just see for yourself.
The tricks I am going to describe allow you to create unique gmail addresses that still hit your existing gmail inbox, without actually making new gmail accounts.
This can be useful in a variety of situations when you need to use multiple email addresses without having the pain of maintaining them, such as
- using unique emails while registering for the same service more than once (say, paypal)
- giving out a unique email address to see if you start getting spam to it later – that way you know exactly who to blame for it
- more generally, easily create email rules to sort incoming emails into folders, delete them,