João escreveu: > Frederico, > > we might end up with something like: > > 1- The client calls an "Hello" Web Service, and the server returns a > random string starting a session with a state "not authenticated" > 2- The client encodes the string using SHA1, and a shared "secret" key > hardcoded on the client, and returns the result to an "Authenticate" > Web-Service > 3- The server makes the same process, and compares it to the string > returned by the client on the Authenticate method, returning a true or > false, and changing the session state to "authenticated" > 4- The client can now call the remote web-services that will check if > the session is set, and it's state is set to "authenticated". > > As i said, this is far from being secure, but for now it seems the > "only" solution. > > BTW, Frederico, are you Portuguese? > > Thanks, > > João Saleiro > > --- In [email protected], <[EMAIL PROTECTED]> wrote: > >> you kept me thinking about this all day. What I suggested early was >> basically what you're thinking on doing, but I believe I now have some >> improvements. >> >> 1- The client communicates with a web-service requesting access >> 2- The server initiates a session, returning a request for validation (a >> string, a char, anything, only to say it's expecting for something) >> 3- The Client converts the current timestamp (like: Date.getMilli()) >> > to a > >> String, substitutes de milli, seconds and minutes digits with 0 (and the >> result is the current hour) and encrypts that key using SHA (or whatever >> one-way algorithm you choose) >> 4- The server does the same, and compares the >> result with the returned encrypted string. If they are the same, the >> session changes it's state to validated, allowing access to the >> web-services. If not, the session is terminated. >> >> This way you would get a semi-random String, only the encrypted version >> would be transmited and that String would be valid for one hour. Plus no >> hard coded key would be needed. I believe your need isn't for a full >> security mechanism, only something that prevents other vendors of using >> your web-service. >> >> Let me know what you think >> >> Frederico >> >> On Fri, 21 Dec 2007 21:47:20 -0000, João <[EMAIL PROTECTED]> wrote: >> >>> We are dealing with one huge client that provides technological >>> solutions based on SAP and .NET. They hired us for developing the >>> presentation layer, and it's damn difficult to make them change the >>> way they work, even if we know that they aren't making the best >>> decisions. >>> Anyway, i don't see how changing from web-services to flash remoting >>> would solve the problem. It's still a SOA architecture, with exposed >>> services, and the only difference is that the data is transferred in >>> binary (but not difficult to be interpreted - even more now with the >>> release of the AMF specification). >>> PKI seems to be the solution, but our expertise is not security. Also, >>> i have doubts on: >>> >>> 1- Does Flex has tools to deal with this kind of things? >>> 2- From what i recall, PKI needs a private key on both sides. This >>> would mean that the key was hard-coded on the Flash Client. >>> >>> I am thinking on something simple like: >>> >>> 1- The client communicates with a web-service requesting access >>> 2- The server initiates a session, returning a random string >>> 3- The client runs some kind of algorithm, made by us, to "encrypt" >>> the string, and returns it. Or, it uses a known algorithm that >>> encrypts the string using a keyword. >>> 4- The server runs the same algorithm on the string, and compares the >>> result with the returned encrypted string. If they are the same, the >>> session changes it's state to validated, allowing access to the >>> web-services. If not, the session is terminated. >>> >>> This is far from being perfect, and far from being secure because the >>> client could be decompiled and the "encryption" algorithm could be >>> easily broken, but at least it would be a bit more reliable than >>> having the web-service completely exposed. We are dealing here with >>> probabilities... >>> >>> What do you think? >>> >>> >>> >>> -- >>> Flexcoders Mailing List >>> FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt >>> Search Archives: >>> > http://www.mail-archive.com/flexcoders%40yahoogroups.com > >>> Yahoo! Groups Links >>> >>> >>> >>> > > > > > -- > Flexcoders Mailing List > FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt > Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com > Yahoo! Groups Links > > > > > __________ NOD32 2747 (20071225) Information __________ > > This message was checked by NOD32 antivirus system. > http://www.eset.com > > > > Joao,
Why don't you use a string based on time instead of a hardcoded one? The system would become pretty secure. Even if someone decompiled the client it would be much harder to understand what was being appended to the random string coming from the server (decompiled AS3 is scrambled, functions are hard to understand, and variables names are lost. A "STRING" would stand out). And yes, I'm portuguese. Frederico
