XML DB

[acidburst]

Hey guys I really need your help.
(just two things)

1. Some time ago (before I started building my website)
i came a cross an open source movie in this website that used an xml document to retrieve usernames and passwords. I spent over and hour searching for it again...but found nothing similar to it. Does anyone know if its been taken off or any other file I could examine?

2. Is it really safe to have a flash movie call an xml db for usernames and passwords? Or is it safer to have the multiple accounts saved within the flash movie?

-thanks

[tupps]

The *best* solution is not to directly access the database but to do something like this:

Flash gets username and password:
Uses 1 way encryption and sends username + cryptoInfo to server (CGI Script).

Server checks cryptoInfo and returns the result. On the server you don't store passwords but simply the results of the 1 way cypher. So this way your passwords can't be decrypted.


Now if you want to come down a step and not use Crypto the better way to do it is to send the username and password to the server and have it return the result. The username and password will be "in the clear" but at least the user will not have access to usernames/passwords.

Remember that anything you store in your Flash file can be read by third parties. So the idea of storing username and passwords in your flash file will make it very weak.

Thanks

Luke

[acidburst]

thanks luke,

I think I like the first method best!
Unfortunately i don't know jack about cgi scripting!
Do you know of a direction to point me to?
Would my host support this method?
thanks again!!

[tupps]

1) is a good choice, it is how Windows NT/2000 and Most Unixes store passwords without letting them be compromised.

If you want to go the first option you need 3 peices:

1st: Cryto Code for Flash (I know someone has written a standard routine for this, which implements a one way crypto routine, I will see if I can track it down).

2nd: CGI script to check the database or text file

3rd: Some way of entering passwords into the system. Depends if you are going to have thousands of people using the system or just a few.

In terms of what scripting you need, it can be done in pratically any language. You could even do it in XML and return the whole passowrd file to the users (which isn't ideal because they would then have a list of usernames with which to hack with).

Also what are you trying to protect? The content in the swf file or information on the server?

Thanks

Luke

[acidburst]

I need to protect the content of the swf file.
Let me know if you track the Cryto Code for Flash
thanks

[tupps]

Sorry about the delay, unfortunately there aren't enough hours in the day at the moment.

However did track this one down:

http://flashexperiments.insh-allah.com/#MD5

Which is the MD5 routine implemented in Flash. This is the same routine that is used by unix servers to encrypt there passwords.

Note that this is a one-way cipher, which means that if someone forgets or can't remember there password it is not possible for you to unencrypt the password. The best option is to set a new password.

Using this routine I would do the following:

Get Username and password from user:

Run password through MD5 routine. Send username and password to server, server verifies that the user is ok.

Now you are wanting to protect the content of your swf file. Now swf files have about as much protection as HTML files so if you deliver everything and then a user opens the swf up with an decompiler you will be exposed. The best way in my mind would be to do this:

User logs in: downloads login.swf
User enters username and passowrd
login.swf runs the password through MD5
login.swf sends username + password to server (say login.cgi).
If user+password correct the login.cgi application delivers the swf content to the login.swf program which loads the deliverable content onto the main stage.
Everyone lives happily ever after!

With this routine only authorised people are the only ones with the oppurtunity to see the deliverable content. Obviosly there is no reason for them to decompile it as they have access to it!

Thanks

Luke

[acidburst]

HA HA!
thanks luke!

This is perfect!
Hey...assuming i made a log-in screen using flash for my website......is it possible for someone to download the .swf file from my server and decompile it to find the access codes? I was very dissapointed to find that one could use a decompiler to open an .swf file and extract the passwords with little knowledge. But can a user actually download the .swf file?

[tupps]

It is possible for people to download your SWF file. It is delivered in exactly the same manner as a web page or image. You will find that the browser may cache the swf as well.

That is why I suggested that you have a login page, which is just a stub file that the user enters the username and password.

Then your cgi-script on the server returns the actual swf that has the content people want to look at. The coding for returning an swf is only a little more tricky than that for returning a web page. Have a look at the file-streaming classes or utilities in most CGI applications.

If you do it this way only the people who have the username/password can access the swf file.

Thanks

Luke

[crunchDesign]

I have been following a ton of your posts lately as I am really trying to start getting into all this DB stuff! your information is GREATLY appreciated...

My question is just kind of expanding on acidburst, when he asked if other people can just get the swf and decompile it. Is there no way somebody could just get a hold of the cgi script and find what the name of the swf is that is being given to the stub?

Also, and this may be a really ignorant question but why is this information being stored in a flash movie? I understand how the UI is getting the information and one way cryptoing it to the server but why not just keep the cryptoed list on the server.. what is being stored in the swf - and how is it getting stored there?

.aaroncrunchie

[acidburst]

So you're tyring to build a DB?
To be honest with you I am scared to build one now that I've come to realize there will never be a "safe" DB. First, if anything is stored in the user's cache, such as a java script or a flash movie, there's a good chance someone will use common sence and decompile it with a cheap $30 program (don't ask me for the name or where to download). Second, if you think saving the password in your host and encrypting your packets will save you...HA! Think again. Packet sniffers and SMB scanners will reveal everything! Don't believe me? Check this link out...play the game... http://www.try2hack.nl/level1.html
When you reach level 6, you will see what I mean.
Good luck
-burst
----------------------------------------------------------
LUke....can you devise a safe login?
Can anyone in this forum put together a inpenetrable login? Using Flash?
[Edited by acidburst on 06-10-2002 at 01:12 AM]

[crunchDesign]

As for safety... that is why cryptography is growing so fast! Well done cyphers are constantly needed in computers these days. Now I know banks aren't perfect but come one if it was _so_ easy to just get into someone's account and steal millions why wouldn't it be done 100's of times over.

Hell doesn't it still take top end computers, linked together, several days or weeks to try and undo 128 bit encryption?

.aaroncrunchie

[acidburst]

Sorry...I didn't mean to upset you (that's the tone I picked up).

....but did you play the game?
What level did you reach?
If you pass level 6.....you would see how weak 128-bit encryption is.

Then again.....if you're stuck in level 2 or 3, then i shouldn't be arguing with you

[crunchDesign]

I'm stuck on 3 LOL everything I know about java says it should just be AbCdE cause your testing string equality! but I'm thinking it's maybe something I typed beforehand... or just something to do with the level names... I don't understand how they will rederict me to something else that is not level4.html

Boo for me.

.aaroncrunchie

PS. No sweats on the "upset" I was just trying to figure out what you were saying and if it was directed to me

[acidburst]

"I don't understand how they will rederict me to something else that is not level4.html"

I don't know if you're being sarcastic or serious...but I am going to believe you seriously could not get to the 4th level!

correction...wrong password will obviously direct to the wrong link!
PASSWORD = "TheCorrectAnswer";
CORRECTSITE = "thelevel4.html";
WRONGSITE = "http://www.disney.com";
-------------------------------------------------------
But this is getting out of hand!
I really wanted you to reach level 8 so you can see how weak this method has become. Follow it here
http://www.try2hack.nl/Level-8.html
Brake it and reach level 9.
You will see that too many have already done so...meaning only one thing!
But wait...you couldn't even reach the 4th level!

[crunchDesign]

I still can't figure out what was up with level 3... I got up to level 8 with some great help from http://www.astalavista.net/member/bo...?tid=18&page=4 Anyway this thread is diverging from it's XML viewpoint so I will stop posting on this thread.

.aaroncrunchie

[tupps]

Just to bring this back on track a little (I will play the hacking game later and join in then!)

> My question is just kind of expanding on acidburst, when he >asked if other people can just get the swf and decompile it. >Is there no way somebody could just get a hold of the cgi >script and find what the name of the swf is that is being >given to the stub?

Two things:

To get the CGI script they would have to get access to internals of the web server (typically the FTP site) as a ordinary web user only ever sees the results of the CGI script (unless of course you have a badly configured web server, please everyone turn the debugging options off on the live servers :-)

The other thing is that the CGI script has access to the entire server not just the publicly accessible areas. So in this example I would set up the server like this:

/data
/public_ftp <--root of the ftp site.
/public_http <--root of the web site.
/public_http/cgi-bin

Anything that is to be password protected should be stored in /data. The CGI scripts after authenticating the user then deliver the content from the /data directory to the user. That way you can't just find the URL and get the content (which stops people who are looking through proxy logs).

Thanks

Luke

[acidburst]

You're right luke:

"That way you can't just find the URL and get the content"

you'd be surprised how many 'professional' websites can be bypased like this!

[tupps]

Yup, definately a lot of sites are like this. The most common one is downloading software with a click through license agreement. Often I want both the MacOS and Windows version of a software and it is not hard to work out from the URL where the software is.

Although that being said, there is a performance hit for a large web site in running it through a CGI script. Also it stops reverse proxies from working, but if you don't have any of that you don't really have to worry.

If I remember correctly Apache has a module which can make sure that the refer is set before downloading files (this stops people stealing images of your site) although I am not sure whether is in Apache 2.0. Also the refer tag can be faked.

Thanks

Luke

[acidburst]

I am not going to put any addresses on the spot light, but bypassing the premium "secure" member log-ins of boards that support html is the second most common
---------------------------------------------------------
This weakness gives flash an advantage.
You have your 'flash haters' arguing that flash criples the internet search engines....but yet they fail to realize that flash also helps prevent search engines from 'accidentaly' leading someone to a restricted page..

[tupps]

That reminds me of a site that I used a lot, but always went through search engines to find the content.

I only realised that I was accessing there premium content when one day I went back to there site through the front page to find the info, and they asked for payment. It must have been a month or two before I realised.

Oh yeah, this was site with info on HTML and web security so you would think they would have known better :-)