Flex Pasta » Everyone should use a Flex Login

Everyone should use a Flex Login

The benefits of using flex for a high traffic login site are enormous!  Even if the rest of the site is not in Flex, the login process should be.  Here are a few reasons why:

  • Security:  Sites where security is important and the login page is open to the public: health care, internet banking, online stores, etc.  Flex is a flash movie, where images, content, forms, are embedded into one file, make it nearly impossible to duplicate for phishing purposes.  HTML websites are open to anyone to steal their code.  Within minutes, a newbie hacker can take a site’s html and have a full functioning phishing website that looks just like the original.  With Flex, stealing a flash file would take highly advanced skills and much more time to come up with the same scheme.
  • Performance: Take an internet banking site for example.  Many of them these days have a multi-step login process.   Step 1) Enter user name, Step 2) Answer a secret question, Step 3) Enter a password if the image shown is the one you picked out.  Internet banking and many other sites heavily rely on the login process.   Many users are just logging in for a quick check of something and then logging off.  Think of the number of transactions an html application makes in this example for the login process alone: 1) Serve the login page. 2) Serve the secret question page. 3) Serve the Password page. 4) Serve the user’s image.  5) Try and Log user in with password entered.  Now with Flex, the SWF file can be placed on the web servers, and once the user has it, they won’t have to download it a second time unless it’s updated.  There is much less but more efficient back in forth with the SWF and the Server:  1) User enters user name.  Request made.  Secret question, secret answer, user’s image is returned.  If the user enters the right answer, we show them their picture, without making a second or third call against the application server.  2) Try and Log user in with password entered.  With Flex, 2 calls are made to the application server vs the 5 with an html app!!  Not to mention the size of the request/response with the Flex app is much smaller.
  • User Experience: Flex has the ability to place cool effects and transitions from step to step on a login process.  When my web app is at peak usage, those transitions make the app seem to move faster than with an html app.  The user won’t feel like they’re using dial up while waiting for the server to respond.  The user will feel more confident with this login process and phishing will be virtually eliminated.

Even if a site is not written in Flex, it can still utilize a Flex login process for the added benefits described above.  Existing sites don’t have to look at Flex and consider a complete rewrite to gain the benefits.  Start with the login process and see what Flex can do to eliminate phishing, improve performance, and add to the user experience!

Sunday, August 24th, 2008 Flex Security Trackback URL for this entry

11 Comments

  • 1. guya replies at 24th August 2008, 11:22 am :

    I was looking for an argument that will tilt the comparison decisively for Flex, imho, these arguments only gives Flex a slight advantage. Performance and User Experience can be resemble to Flex when good Ajax is used.
    Agree that a Flex website is more difficult to duplicate for phishing purposes, but, that won’t stop the motivated attacker.

  • 2. Brian Telintelo replies at 24th August 2008, 12:02 pm :

    Yes, a good ajax site could rival flex in user experience and performance. However, flex using amf is proven to be significantly faster than an ajax transfer. On an large scale application, this is a big difference. Many sites use the Gomez Benchmark to monitor login times. Every millisecond is important.

  • 3. but.. replies at 24th August 2008, 1:18 pm :

    The smallest Flex app I’ve ever built is >100K. Is this worth it for a login?

  • 4. Nathan Levesque replies at 24th August 2008, 1:40 pm :

    I would have to argue against this with a few points:

    1) If your security problems are that bad, a client side solution should be the last thing you think of because they’ll never be secure, let the server worry about security. SWF decompiling has been around for a while, and you’re only adding a layer of obscurity (and a relatively weak one).

    2) You’re now requiring me to have Flash installed to log into your site (potentially none of which uses Flash).

    3) As to your comment #2: If you’re worried about loosing milliseconds during login, how long does a new (or cache-cleared) user have to wait to be able to enter their login info while the swf loads vs. the increase in performance of amf and which would you rather wait for?

    I’m all about using Flex wherever I can, especially since it’s what I do for a living; I just don’t think this is a proper use for it but I would be glad to be proved wrong!

  • 5. Aral Balkan replies at 24th August 2008, 2:24 pm :

    And make people download 100K+ for a login form?

    I don’t see how using Flex would make it harder for someone to create a phishing scam. It’s easy enough to create a screen grab of the site and create an HTML version. How many users will notice the difference or even know/care that it’s Flash as long as it works. If anything, your argument relies on it being more difficult to create Flex applications than HTML, which (a) I don’t believe to be true and (b) if it were true, it would be a sad thing for Flex.

    A simple feature like a login form is probably the worst use case for a Flex application unless the whole site is a Flex application (in which case, the continuity of the user experience alone will be worth the download.)

  • 6. Jim replies at 24th August 2008, 9:07 pm :

    Flex is great when used appropriately, but a login screen is not in my opinion a good use for it I’m afraid.
    There’s a big download overhead for the flex framework, and nothing you describe could not be done with flash alone without including the flex framework. Flex is only a framework implemented in the flash player at the end of the day.
    For a login screen I wouldn’t even recommend flash ( even without flex framework), however.
    At the end of the day, how many login screens do you see that are done in flash player that are not part of a swf? There are reasons for that, It’s not that people have overlooked what’s available to them. People have been doing this stuff for years now and they use what works, in general.
    Sorry, I love flash & flex, earn my living from and love to see enthusiasm about them (such as yours), but I do think this point is, well, a bit off the mark.

  • 7. Kristof Neirynck replies at 25th August 2008, 4:29 am :

    This is the worst idea ever. Using Flex for login disables the browsers capability to store both login and password. This will annoy many users. I personally would rather implement everything but the login process in Flex.

  • 8. Mark Lapasa replies at 26th August 2008, 6:45 am :

    @Kristof: Caching L/P is something SharedObject can handle. No problem re-creating the same experience.

  • 9. Brian Telintelo replies at 30th August 2008, 10:28 am :

    I think a several good points have been made against Flex for Login. I would still agree with Guya that it would be harder to phish a flex site than a normal html site. Flex provides a unique UI that is harder to duplicate, and there is no “source” that any one can just take as there is with HTML.

    Nathan - You point about requiring a user to have flash player for the site is one to consider. However, in this day of the internet, must we still hold back what direction to build our website because we are afraid of requiring the user to have flash? 98% of browser’s have flash player and it is easy to download and install.

  • 10. Joeflash replies at 1st September 2008, 10:40 pm :

    I would agree with a few here: having been a Flash/Flex developer for nearly ten years, I can say that a Flex login for a non-Flash site is the worst use of a Flash Player application that I can envision. At first glance it seems like a good idea, because a SWF, being a binary format, can give the illusion of security, and the UI is easy to build. However:

    a) A SWF is anything but secure, and can be cracked with the right software. If your authentication routine is encoded in the SWF, you’re in for a world of hurt. And the somersaults necessary to create a secure login authentication from a SWF app, plus cached user/login with SharedObject far outweigh the effort of creating a server-side login from HTML served up from PHP/ASP or a backend language.

    b) Obliging the user to endure an additional 250K+ download right off the bat by using the Flex Framework for a simple login is total overkill. Even if a case could actually be made for a SWF login app for a non-Flash site (see below), you should use a Flash/AS3-developed login app, without the overhead of the Flex Framework.

    c) Using a Flex login as a gateway application to a non-Flash/Flex site necessitating the Flash Player is really no better than all those skip intros which gave Flash such a bad name all those years ago, and is incredibly bad usability.

    In sum, DON’T DO IT. Please. I beg you. For the children… :)

    Even if the login were intended for a larger Flex application, a strong UI case would need to be made for the login to be included in the Flex application itself. For simple Flex applications where the actual login data is not crucial to the application, a non-SWF server-side login should be used. And if the login state is important to the application, as in the case of Acrobat.com, use of SharedObject to cache the user data and history states should be used.

  • 11. Brian Telintelo replies at 13th September 2008, 8:44 am :

    Enough have spoken. Don’t use Flex just for Login!!!!