Password encrypted using sql server login

Hi,

can anyone tell me if I use SQL server login without SSL how the password is
sent over the wire to sql server? Is it encrypted or clear text? From the
microsoft docs I couldn't find a clear answer about this.

kind regards,

Christiaan

Christiaan,

login and password are sent as plain text if not using SSL.

Hope that helps,

momo

Thanks for the answer Mormo. If I understand it correctly, using SSL will
encrypt all data being sent which comes with a performance penalty. Is there a
way to encrypt the password only? So without the overhead of everything being
encrypted?

kind regards,

Christiaan

Christiaan,

you are right, but the performance penalty of using SSL will be negligible
small in almost all real-life scenarios. Maybe you should simply give it a try
and see if it's really doing any harm. But if SSL is no option, you could use
Windows authentication (NTLM) so at least the password isn't transferred over
the network (from what I understood is your primary concern).

Cheers,

momo

Technically when using SQL Server Login the password is obfusticated using a
basic algorithm. It's not plain text but anyone with a little bit of knowledge
can easily de-obfusticate it so it is hardly any better than plain text.

Using SSL and Windows authentication are the way to go if you are concerned
about security.

Brett,

I'm not even aware of any obfuscation. If I remember correctly, both strings,
login and password, are simply written to the socket as byte arrays (using the
specified encoding) so anyone sniffing the network traffic is able to simply
read them as plain text. Or am I missing something?

Cheers,

momo

Momo,

As per the TDS specification at http://msdn.microsoft.com/en-
us/library/dd304523%28v=PROT.13%29.aspx

2.2.6.3 LOGIN7:

Before submitting a password from the client to the server, for every byte
in the password buffer starting with the position pointed to by IbPassword,
the client SHOULD first swap the four high bits with the four low bits and
then do a bit-XOR with 0xA5 (10100101). After reading a submitted password,
for every byte in the password buffer starting with the position pointed to by
IbPassword, the server SHOULD first do a bit-XOR with 0xA5 (10100101) and then
swap the four high bits with the four low bits.

Oh, thanks for clarifying! I'm quite sure that jTDS doesn't do anything like
that, but even if it's a really weak protection, we should implement that,
nevertheless. Thank you for the hint!

Cheers,

momo