10 Replies Latest reply on Dec 12, 2006 12:22 PM by Bob_Robertson

    Secure transactions with Flash frontend

    Bob_Robertson Level 1
      Hello again to everyone. I've been working on an interactive exercise, and am getting steadily closer to deployment. The scenario is this: I have a database of users and teachers, each with a unique ID number and a password. Other tables in the same database are tables of faults assigned, faults resolved, classes, programs used in those classes, and a big nasty table that links users, classes, and programs together. The users and teachers can modify records in the database by making calls to several PHP scripts on the server. Each script has a separate database account. My goal is to authenticate each call to one of those scripts, so that unauthorized people can't modify the database. Most of our anticipated clientele uniquely identify their students with their Social Security Numbers.

      With that in mind, I'm trying to avoid sending their ID numbers in the clear. Should I just tell them that people can see their traffic, and not to use any critical info? The md5 and sha hashes have been cracked into the realm of computational feasability; should I just encrypt sensitive traffic with a randomly generated key? Alternately, I could probably convince my higher-ups to get an encryption certificate, or just create my own. In that case, if the page is encrypted, would traffic from a flash movie embedded in that page be encrypted as well?

      Any thoughts, ideas, or discussion is welcome and appreciated.
        • 1. Secure transactions with Flash frontend
          Bob_Robertson Level 1
          Alright, I've thought about this some, and we don't actually need to store the SSN. That was just a convenient way of guaranteeing a unique number that I could use as a primary key. So, I'll store a unique username/password pair, which will have to be checked by scripts to add users, and generate the user number automatically. I'll also just tell teachers not to create user accounts using the student's full SSN as the username. That way, personally sensitive info isn't broadcast in the clear at all, and my concerns about our company being liable for some *******'s SSN being stolen are alleviated.

          That still leaves the question of how to authenticate users and teachers so that a malicious person can't access the control scripts and bugger the database. I suppose I could just make a general script that processes arbitrary requests, and be really careful about authentication, but that just reduces the maintenance scale of the problem, and potentially opens up several nasty holes (like dropping entire tables). I suppose that I could restrict the abilities granted to the general account, but again, that doesn't solve the problem of proving that a user is supposed to be able to do those things.

          Ideas?
          • 2. Re: Secure transactions with Flash frontend
            anonymous thing Level 1
            the first thing is to use SSL... Validate url referrer of client and check for ip in your blacklist . Then, client can connect on your server and stock an unique token, md5, sha, a shared key or what you want. When you perform that, use a very restrictive account on your DB; read only with a write permission on a unique table. Add your token and IP in this table. Return token to your client.

            Now, your client will enter his login and password and he will send is token to the server. On server, you will connect to your DB with another account with different permissions(very restrictive) to valide token with current IP and after that you will validate login and password. If everything is successful then return only an id(an other token) that you will stock in another table. It's this id that you will compare to get the real id of your client. So, your client computer never know the real info from DB. It's like a session Id... Never use local shared object, hidden field, cookie, session cookie to stock real info from DB.

            If you have FMS, you can use it to call WebServices an to stock data on it. This way you can protect you DB if FMS is the only way to enter...
            • 3. Re: Secure transactions with Flash frontend
              MotionMaker Level 1
              You might explore Session keys in PHP. Expire them after a period of inactivity, renew as long as activity occurs.
              • 4. Re: Secure transactions with Flash frontend
                Bob_Robertson Level 1
                Okay, so if I understand this correctly, the steps here are:
                1)Client connects via SSL to server.
                2)Server verifies desirability of client, and returns token via SSL if client is approved.
                3)Client then sends token, username and password, to server (still over SSL).
                4)Server generates ID token and sends it to client, which then stores it for future reference.
                5)Future transactions proceed in cleartext.
                ...
                n) (at end of session) Server removes ID token from table of approved users, and removes first token from its table as well.

                Questions: if the ID token is sent to the server as proof that the client is authorized, isn't it sniffable? Or are you assuming an SSL connection for the entirety of the session?
                • 5. Re: Secure transactions with Flash frontend
                  Level 7
                  Like MotionMaker mentioned, I'd do this with Sessions as you're using PHP
                  anyway.

                  --
                  Dave -
                  Head Developer
                  www.blurredistinction.com
                  Adobe Community Expert
                  http://www.adobe.com/communities/experts/


                  • 6. Re: Secure transactions with Flash frontend
                    Bob_Robertson Level 1
                    Okay, after researching it some, it looks like sessions are the way to ensure that only authorized people can access the DB scripts. But the thing that I don't understand is how to securely send the name/password attempt. My worry is that a potential attacker would be able to sniff both form data and the content of incoming pages, and so would be able to see the name/password attempts of legitimate users, who presumably succeed most of the time. The attacker would then have name and password pairs for every person who logged on during the period of observation.

                    Is SSL the solution for this? If so, how do I use it correctly? I'll keep researching this, of course, but I'm still confused.
                    • 7. Re: Secure transactions with Flash frontend
                      jonnybennett Level 1
                      What sort of data are you storing in the database???... unless you are storing really important personal details, surely posting the username and password over SSL is enough security?
                      • 8. Re: Secure transactions with Flash frontend
                        MotionMaker Level 1
                        SSL encryption for all sensitive data comm -- for your concern at least through login validation. Then you can switch to http if you want.

                        The session token can be sent with or without SSL protocols.
                        • 9. Re: Secure transactions with Flash frontend
                          Level 7
                          SSL encryption for all sensitive data comm -- for your concern at least through
                          login validation. Then you can switch to http if you want.

                          The session token can be sent with or without SSL protocols.


                          • 10. Re: Secure transactions with Flash frontend
                            Bob_Robertson Level 1
                            Thanks for your feedback, folks. I think I've got matters figured out; now all that's left is the implementation.


                            Wonder how many doomed coders have said that little gem...