password sent in plain text during user auth

[GoogleCodeExporter]

Which version of OpenMeetings are you running?
latest

The problem is, passwords in database are stored in hashes, but the auth 
process itself isn't safe - when the user enters password via frontend, 
it's sent in plain text, and any sniffer is able to catch it. Only then 
it's crypted and compared to hashes in database or sent in plain text to 
the LDAP server. What I am offering is to make the process safer - to hash 
it right in the laszlo script, then send hash to the server, where you can 
compare it to the database hash or do a LDAP auth, as far as I know, LDAP 
supports auth using MD5 hashes if you add {MD5} to the start of the 
password string.
 There is a good JavaScript class under BSD license which may be used for 
it, made by Paul Johnston (http://pajhome.org.uk/crypt/md5/), as well as 
many versions like ActionScript class etc.
 So I am about to research in this direction now. Any help would be 
appreciated.

Original issue reported on code.google.com by volkov.r...@gmail.com on 8 Apr 2009 at 10:16

[GoogleCodeExporter]

Rodion,

Is it possible to download a function implementation from the side using 
something
like <script src=""> (see a description of the script tag at
http://www.openlaszlo.org/lps4.3/docs/reference/)? In this way we are using 
dynamic
linking when call the function, hence there are no LGPL restrictions.

Original comment by alexei.f...@gmail.com on 8 Apr 2009 at 10:29

[GoogleCodeExporter]

Yes, it was possible, thanks for the tip. MD5 succesfully created client-side 
with 
dynamically linked code from Paul, so I am implementing further.

Original comment by volkov.r...@gmail.com on 8 Apr 2009 at 10:46

[GoogleCodeExporter]

Small update on the situation. I have faced a serious problem I cannot solve 
alone - 
LDAP. First of all, currently we are using Active Directory server as a LDAP 
server, 
and I was trying to implement MD5 auth there. The case is, MD5-encrypted 
authentification process is implementable by changing some lines of code (see 
patch), 
but it still has some serious limitations - for example, for it to work with my 
record I had to change my password in AD to be stored in reversible encryption, 
and 
reset it, and the server side making ldap call still has to have the password 
in 
plain text, I cannot authenticate with "{MD5}" + hash_from_client as a password 
as I 
thought before. This is reasonable though - you can steal a hash from somewhere 
this 
should not mean you are the user - anyway, in current form, I can't say how to 
send 
password encrypted and have it in plain text on a server at the same time. The 
only 
solution I see now is to implement some kind of LDAP "proxy" - a server acts as 
a 
transmitter of LDAP requests between client and LDAP server, therefore it does 
not 
need password in plain text.

Original comment by volkov.r...@gmail.com on 9 Apr 2009 at 12:47

[GoogleCodeExporter]

Sorry, forgot the patch - attached (apply to the latest SVN version)

Original comment by volkov.r...@gmail.com on 9 Apr 2009 at 12:53

Attachments:

• md5_encrypted_auth_ldap.patch

[GoogleCodeExporter]

Here is a nice link on SASL authentication
http://java.sun.com/products/jndi/tutorial/ldap/security/sasl.html

Original comment by alexei.f...@gmail.com on 9 Apr 2009 at 2:18

[GoogleCodeExporter]

Here is a better example of SASL challenge processing:
http://java.sun.com/javase/6/docs/api/javax/security/sasl/SaslClient.html

Original comment by alexei.f...@gmail.com on 10 Apr 2009 at 7:05

[GoogleCodeExporter]

hola,

an optional MD5 authentication would be a real effort, i think... if u want to 
avoid 
sending the password from client in plain text, u should make it configurable 
for 
the whole application (-> Config Val set via Install Servlet).

see ya

Smoeker

Original comment by i...@oliver-becherer.name on 14 Apr 2009 at 8:16

[GoogleCodeExporter]

I am sorry, but I cannot implement MD5 authentication right now, the problem is 
in 
Active Directory - many hours spent on the subject still haven't answered the 
main 
question - whether it is possible to authenticate client on an AD server having 
only 
his hash, but not password. This is the main question and without an answer to 
it the  
encryption on the client side is not possible. Though, I have looked in the 
other 
direction - using the encoded stream (rtmps) to transfer all the data, and 
fortunately, OpenMeetings allows to do that. Patch enabling rtmps is attached, 
currently it uses port 8443, because in my Red5 root/conf/red5.properties the 
line 
says rtmps.port=8443. If it says something other than that in yours you should 
change 
the patch accordingly. I have also noticed, that rtmps only starts to work if 
you 
restart the red5 server and clear the cache of your browser at the same time. 
Sebastian has already underlined the main minus of this solution - rtmps does 
not 
work on Linux Flash player out of the box, but I have found some articles like 
this 
one - 
http://labs.adobe.com/wiki/index.php/Flash_Player:Additional_Interface_Support_f
or_Li
nux#Source_code
And they say, they can make flash player 9 to work with rtmps on linux, it 
should 
mean that there should be the same or similar way to enable it under flash 
payer 10. 
So I am currently looking in this direction, if we can enable rtmps in linux, 
we 
don't need to crypt the password on the client side anymore, therefore we don't 
have 
much problems with LDAP authentication using hashes. But, still, there is one 
more 
way, just in case - there are some articles on AD authentication in java, which 
suggest talking to AD seperately, to consider it as something different than 
just an 
LDAP server. Because, actually, AD being a decent stuff itself isn't so good as 
a 
LDAP server at all. So here are the links on the articles:
http://weblogs.java.net/blog/kohsuke/archive/2008/01/active_director.html
http://weblogs.java.net/blog/kohsuke/archive/2008/06/more_active_dir.html

Original comment by volkov.r...@gmail.com on 15 Apr 2009 at 9:51

Attachments:

• enable_rtmps_8443.patch

[GoogleCodeExporter]

After a bit of study on the rtmps functionality on Linux I've decided that it 
would 
be more productive to wait for Adobe to finish their rtmps. Because all the 
solution 
I've come into are too ugly and complex to implement. So the work on this issue 
is 
currently suspended. Switching to bugfixing now.

Original comment by volkov.r...@gmail.com on 17 Apr 2009 at 7:54

[GoogleCodeExporter]

Hi

I have the same problem you say. When I connect to openmmetings, LDAP password 
is
sent in plain text...
So, if I understand, if I use rtmpts, LDAP is not sent in plain text, isn't it ?

I configure my red5.properties like you say:
rtmpts.port = 8443
https.port = 8443

In config.xml, I autorize SSL and rtmpsslport is 8443.

Then, I try to connect openmeetings at :

https://myip:8443/openmeetings/

I must have certificats so I downloaded it but after it says me :

HTTP Status 404 - /openmeetings

type Status report

message /openmeetings

description The requested resource (/openmeetings) is not available.

Could you help me ?

Thanks

Bidab

Original comment by ivan.bol...@gmail.com on 14 May 2009 at 8:44

[GoogleCodeExporter]

I precise I use openmetings 0.7rc1 on ubuntu 9.04 and I try to access from 
Windows
computer...

Thanks

Original comment by ivan.bol...@gmail.com on 14 May 2009 at 8:47

[GoogleCodeExporter]

No, actually you are slightly wrong at what you are trying to do. In order to 
implement SSL authentication and further work with SSL you have to have the 
following 
lines in your OpenMeetings' config.xml file:

<rtmpsslport>8443</rtmpsslport>
<!--
Wether it should try to connect to rtmps first or not
Valid values: yes / no

NOTE: The OSx and Linux Flash Player are NOT able to connect via rtmps
The support for Windows is experimental
 -->
<useSSL>yes</useSSL>

As well as your Red5/conf/red5.properties should contain the following section:

# RTMPS
rtmps.host=0.0.0.0
rtmps.port=8443
rtmps.ping_interval=5000
rtmps.max_inactivity=60000
rtmps.max_keep_alive_requests=-1
rtmps.max_threads=20
rtmps.acceptor_thread_count=2
rtmps.processor_cache=20
# RTMPS Keystore Password
rtmps.keystorepass=password

And SSL will be used any time you connect to your openmeetings with your 
typical URL, 
say http://localhost:5080/openmeetings. No need to change the port or 
something. But, 
this all will work only with Windows, flash on Linux doesn't support rtmps yet.

But, this all is valid for client-to-server transactions. As for LDAP, after 
the 
password is sent to server, it will try to authenticate with LDAP server and 
password 
will be sent in plain text between those two servers, to avoid that you should 
use 
the patch attached above, it should implement MD5 encrypted authentication. 
Unfortunately, at the moment it works with Windows AD servers only if passwords 
are 
stored in reversible encryption, which by itself is a security flaw.

Original comment by volkov.r...@gmail.com on 14 May 2009 at 9:00

[GoogleCodeExporter]

Hi

Yes, I have found that after, it's ok for SSL...

I try your patch for LDAP but connection doesn't work (see my attachment).

Is it beacause of passwords are perhaps not stored in reversible encryption ?

Thanks 

Original comment by ivan.bol...@gmail.com on 14 May 2009 at 11:22

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

It's better with attachment...

Original comment by ivan.bol...@gmail.com on 14 May 2009 at 11:25

Attachments:

• ldap.jpg

[GoogleCodeExporter]

you should read the OpenMeetings logs - obviously you got an exception during 
LDAP 
authentication

Original comment by volkov.r...@gmail.com on 14 May 2009 at 11:28

[GoogleCodeExporter]

Hi,

This is the log:

LdapLoginmanagement.readConfig :
/home/ivan/Bureau/OM/webapps/openmeetings/conf/om_ldap.cfg
2009-05-14 13:17:52,813 [pool-4-thread-16] DEBUG 
o.o.app.data.user.Usermanagement -
LdapAuthBase.java 212507 65 org.openmeetings.app.data.user.Usermanagement
[pool-4-thread-16] - LdapAuthBase
2009-05-14 13:17:52,813 [pool-4-thread-16] DEBUG 
o.o.app.data.user.Usermanagement -
LdapAuthBase.java 212507 82 org.openmeetings.app.data.user.Usermanagement
[pool-4-thread-16] - authenticateUser
2009-05-14 13:17:52,814 [pool-4-thread-16] DEBUG 
o.o.app.data.user.Usermanagement -
LdapAuthBase.java 212508 93 org.openmeetings.app.data.user.Usermanagement
[pool-4-thread-16] - {MD5}"my_pass_is_write_here"
2009-05-14 13:17:52,814 [pool-4-thread-16] ERROR 
o.o.app.data.user.Usermanagement -
LdapLoginManagement.java 212508 191 
org.openmeetings.app.data.user.Usermanagement
[pool-4-thread-16] - Error on LdapAuth : null

Bidab

Original comment by ivan.bol...@gmail.com on 14 May 2009 at 11:54

[GoogleCodeExporter]

Do you mean the ssl connection doesn't work with linux on the client side? Or 
do you
really mean, that I can't use Linux as Server when I want to use SSL? Or do you 
just
linux clients can't work with it?!

Best Regards,
Markus

Original comment by SFree...@gmail.com on 19 Oct 2009 at 12:25

[GoogleCodeExporter]

OK, just got it by myself. Of course, it works on Linux Servers...

But to use it you have to uncomment the RTMPS Area in the red5-core.xml. This 
Area
should begin in Line 166.

Hope this will help someone...

Original comment by SFree...@gmail.com on 19 Oct 2009 at 1:30

[GoogleCodeExporter]

Original comment by seba.wag...@gmail.com on 31 Jan 2012 at 12:23

• Added labels: Restrict-AddIssueComment-Commit

[GoogleCodeExporter]

OpenMeetings moves to Apache Foundation, update your bookmarks to the new 
project page:

http://incubator.apache.org/openmeetings/

New Issue tracker is located: https://issues.apache.org/jira/browse/OPENMEETINGS

New Mailing Lists located at: 
http://incubator.apache.org/openmeetings/mail-lists.html 

Original comment by seba.wag...@gmail.com on 31 Jan 2012 at 12:25