Login security concept?

[Hansolo]

Re: Login security concept?

Guess I am not being clear.

When I navigate my browser to http:\\myserver\mypage.a5w I have in effect requested mypage.a5w from the server. The server gets to do whatever processing is needed to the page before it is ever viewed (or used) by the client. In fact it has to in the case of Xbasic grids.

If I had a Grid defined by Xbasic on this page it would be visible without any input from me other than my telling the browser to get that page. The WAS created what was needed for HTML viewing based on the Xbasic before I even got the page.

What if MD5() was not much more than a place holder that told the WAS to embedd the approprate JavaScript in the page sent to the client that would encrypt the contents of the password textbox in the dialog. This all occures before the client even gets a look at the page.

Is the MD5() function used by the WAS to create an embedded script prior to sending the page requested by the client browser, thereby adding the ability to encrypt the password on the client side. You understand that all this is done done simply by the clients initial request for the page.

Has anyone looked at the source in the browser that results following a page requested from the WAS that included the MD5() function. I'll bet it has some interesting additional scripting (not Xbasic).

:-)

[Peter.Greulich]

Re: Login security concept?

Has anyone looked at the source in the browser that results following a page requested from the WAS that included the MD5() function. I'll bet it has some interesting additional scripting (not Xbasic).
:-)

Ok, Hansolo. That's an interesting theory. Still, I doubt that Alpha programmed a Javascript version of MD5() and all the other xbasic encryption methods. It must be something else. If only Lenny would enlighten us.

[Steve Wood]

Re: Login security concept?

Chuck, I sent an email to Lenny to ask this question before I saw your last post. As I was writing my email, and referring to the Alpha Help in this area, I think your assumption is correct. I bet the WAS converts all script to equivalent javascript and html and the browser only sees that, no xbasic whatsoever. I will report if Lenny responds directly.

[Peter.Greulich]

Re: Login security concept?

Steve, You don't really believe that Alpha created a parallel language converting xbasic to Javascript do you? It took Alpha years and years to develop xbasic. How could they in relativley short order create a translation program to javascript for thousands of xbasic commands? It just don't add up.

[Doug Page]

Re: Login security concept?

Maybe Chris can chime in and tell us what the view source is showing on his working model above.

[Hansolo]

Re: Login security concept?

Steve, You don't really believe that Alpha created a parallel language converting xbasic to Javascript do you? It took Alpha years and years to develop xbasic. How could they in relativley short order create a translation program to javascript for thousands of xbasic commands? It just don't add up.

I am not suggesting all Xbasic functions are handled this way but obviously some could be. How the heck do you think the browser shows a table filled with data created from and Alpha5 Xbasic Grid component. As we all know the browser has no idea what Xbasic is and the beauty of the WAS is that it takes Xbasic and translates to something the browser is intrinsically capable of dealing with based on Standards in HTML and yes even JavaScript.

In fact, wasn't their a bug some revisions back where some JavaScript from a source file used by Alpha during the compilation of publishing the a5w pages with a certain component was being corrupted intermittently. I think the workaround was to replace a source file each time the problem occured at the time.

Peter - If I were making a program that allowed JavaScript like functionality but did not want to require the user to learn JavaScript you bet I would wrap it in my own functions. And this does not have to be a conversion process but a simple cut and paste MyFunction = ThisJava(resource file, line#) and pass it the needed object to parce into the script.

But I am most likely wrong.. Just having a good time thinking about it! :-)

[Steve Wood]

Re: Login security concept?

Although it just increases the mystery in my mind, Lenny responeded to this question:

...the browser does not know Xbasic, nor do components or A5W pages send Xbasic to it...

In the Alpha Help topic How Pages are Rendered says, in David Byrne lyric, "Perhaps you ask yourself, "How does the browser know what to do with Xbasic?". The answer is that the Web Application Server processes the Xbasic code and replaces it with standard HTML and JavaScript. "

[jmatienza]

Re: Login security concept?

Take a look at this page from the help file. Look at the graphic in particular.

[Steve Wood]

Re: Login security concept?

Here is the answer to this question. The password travels across the internet in clear text regardless of what method you may deploy using MD5() or other encryption using xbasic.

I set up tcp packet sniffers on both remote and server and tested with various setups. Comments here are correct, Xbasic happens on the server; the login dialog HAS to transmit the password as entered.

I have unintentionally misled many people on this subject.

A good plan now would be to work on a true server-initiated challenge/response method or to deploy javascript on the client that encrypts the password before transmission.

From my obserevation, SSL does properly encrypt all transactions.

[Peter.Greulich]

Re: Login security concept?

The password travels across the internet in clear text regardless of what method you may deploy using MD5() or other encryption using xbasic.
...
From my obserevation, SSL does properly encrypt all transactions.

Ok. So I guess MD5(), etc. is a placebo, then?

Sure SSL works since that functionality is built into the browser.

[Steve Wood]

Re: Login security concept?

Not really. By usng MD5() in the login process I allow the client to remove (i.e. not retain) the actual password in the Users table. In my systems you add a password by clicking a New Password button. It asks the password twice, generates and writes the hash value to the database and discards the actual password. If someone were to steal your database, they at least could not get everyone's password. This also hides the password from other employees - no one but the user knows what the password is. If they forget, the system, on request, creates a new random password for them, emails it to them. Then they can change it once they log in.

Back on the reverse-engineering of an encrypted password. I don't think its correct that you can easily reverse a hash value. The methods I reviewed worked on "guessing" the value by throwing a million guesses at it. There are databases containing the most common million passwords people use, and throwing those, one at a time, is one of the 'hack' methods.

[Peter.Greulich]

Re: Login security concept?

The methods I reviewed worked on "guessing" the value by throwing a million guesses at it. There are databases containing the most common million passwords people use, and throwing those, one at a time, is one of the 'hack' methods.

the most common million passwords people use - Ha ha ha !

That cracks me up. "common"? "million"? oxymoron or what? :)

[Lenny Forziati]

Re: Login security concept?

Ok, Hansolo. That's an interesting theory. Still, I doubt that Alpha programmed a Javascript version of MD5() and all the other xbasic encryption methods. It must be something else. If only Lenny would enlighten us.

First, I believe you (non-specifically, not just Peter) are overly concerned about a non-issue because of a lack of understanding. I'm not saying security is a non-issue, it is very serious business. Rather the discussion of how the browser could execute the Xbasic md5() function is a fruitless diversion. Browsers cannot execute Xbasic and they do not need to. That is the server's job.

As Steve has already pointed out, the browser is sending the clear-text password, unless you have added JavaScript to hash it yourself. But hashing passwords is not intended to protect your info while it is on the wire a simple hash should not be used to secure data in transit. It is not an encryption algorithm, rather it is a one-way hash and cannot be decrypted, though md5 collisions can be generated without much effort. Also, performing the hash on the client would expose the has algorithm to potential crackers.

SSL was created expressly for the purpose of data encryption when sending across the Internet and is what should be used if you want your data to be safe as it travels the network. If you need to send a password, hashed or not, use SSL. SSL is based on a public key/private key pair and uses a strong encryption algorithm*. The packet sniffing done by Steve would be impossible with SSL, he would just see a bunch of garbage.

The reason for hashing passwords is to secure them on the back-end. If your user table were to fall into the wrong hands, and your passwords were not hashed, the person that acquired your table would also know everybody's password. And since we're all guilty of using the same password more places than we should, not only has your application been compromised, but potentially so has your users' web mail, online banking, etc. You might even be legally liable for such a breach if you have not taken steps to protect the sensitive info.

When I do use an md5 hash, I never hash the plain password. You should always use a "salt" as part of your hash to protect against dictionary attacks and other ways to break the passwords. For a simplified example, instead of md5("MyPassword"), I would do md5("this is some salt text that only I know" + "MyPassword"). And you would never want to repeat this algorithm on the client because then your additional measure is fully exposed and defeated.

Incidentally, md5 is a well known algorithm and is already implemented in JavaScript so we wouldn't have to go out and implement it ourselves. We have in fact created some Xbasic->JavaScript conversion routines, but md5() is not one of them. But as I mentioned, I wouldn't be using md5 on the client to hash the password anyway.

Web applications are fundamentally different in architecture from the desktop world that you may be more accustomed to. I recommend some review of client-server interaction in web applications as well as web-related security topics. There is a bit of info in our documentation, but Google will turn up much more. The concepts are the same regardless of the server platform, so if you find a great article that refers to PHP for example, 95% of it is still going to be applicable to your A5W pages. I'll also try to dig up my notes from the security presentation I gave at the users conference 2 years ago to make available.



*SSL actually has a number of algorithms available to it with a number of key lengths. When you visit an SSL-enabled web site, you can view the view the encryption details, as shown here:

[Peter.Greulich]

Re: Login security concept?

First, I believe you (non-specifically, not just Peter) are overly concerned about a non-issue because of a lack of understanding.

Lenny,

Thanks for your learned response. I can't speak for others, but I wasn't overly concerned about encryption, rather I was trying to understand how that could possibly work, so I could better understand WAS/web functionality. As one might logically expect, and as you and Steve have pointed out, it doesn't "work". This has been a great education for me, certainly. I learned something important. And I very much appreciate everyone's input and comments.

[Steve Wood]

Re: Login security concept?

Peter,

I used to keep clear passwords in my users table, now I don't. When I did, I also had no rules about password creation, they could create whatever they wanted. I saw passwords such as jane (their own name), password1, ppp, or really tricky, kathy when their name was spelled cathy. Now passwords have to be 6+ length, contain a digit not as the first or last character, not contain their login ID, and a few other rules.