Isn't is true that passwords and keys are sent un-hashed to the BNLS server, and anyone with access to the server, if they wanted to, not saying the would, could retrieve keys / usernames / passwords?

[quote author=David link=topic=13085.msg131737#msg131737 date=1129927620]
Isn't is true that passwords and keys are sent un-hashed to the BNLS server, and anyone with access to the server, if they wanted to, not saying the would, could retrieve keys / usernames / passwords?
[/quote]

Uh huh.  So what's your point?

I don't have issues with it, I personally use BNLS, but someone was trying to tell a buddy of mine that they cannot retrieve the passwords and keys from the server.

[quote author=David link=topic=13085.msg131752#msg131752 date=1129940709]I don't have issues with it, I personally use BNLS, but someone was trying to tell a buddy of mine that they cannot retrieve the passwords and keys from the server.[/quote]

Well, that someone probably cannot. :)  BNLS doesn't log any of that data, and the only other way to capture it would be by doing a wire capture of the inbound traffic.  Given the volume of data that the vL server moves (BNLS, botnet, TeamSpeak, etc.), doing a wire capture is not fun.  I wanted to do it once to try to debug some strangeness with one of our other services.  It did not go well. :)

Also if the login isnt for w3. BNLS never gets the Username.

[quote author=Kp link=topic=13085.msg131755#msg131755 date=1129942524]
[quote author=David link=topic=13085.msg131752#msg131752 date=1129940709]I don't have issues with it, I personally use BNLS, but someone was trying to tell a buddy of mine that they cannot retrieve the passwords and keys from the server.[/quote]

Well, that someone probably cannot. :) BNLS doesn't log any of that data, and the only other way to capture it would be by doing a wire capture of the inbound traffic. Given the volume of data that the vL server moves (BNLS, botnet, TeamSpeak, etc.), doing a wire capture is not fun. I wanted to do it once to try to debug some strangeness with one of our other services. It did not go well. :)
[/quote]

Ethereal filter, ((tcp.port == 9367)). You've got the BNLS traffic. Nothing more, nothing less. =)

Think of it this way: with all the thousands of logins at any given time, if they wanted to steal a key, what is the chance that it would be yours?

[quote author=The-FooL link=topic=13085.msg131764#msg131764 date=1129956091]
Think of it this way: with all the thousands of logins at any given time, if they wanted to steal a key, what is the chance that it would be yours?
[/quote]

They wouldn't want it, period.

If they were to require that the passwords and/or CD-Keys be hashed before they were transmitted, it would defeat the purpose of using BNLS.

[quote author=Joe link=topic=13085.msg131758#msg131758 date=1129948596][quote author=Kp link=topic=13085.msg131755#msg131755 date=1129942524][quote author=David link=topic=13085.msg131752#msg131752 date=1129940709]I don't have issues with it, I personally use BNLS, but someone was trying to tell a buddy of mine that they cannot retrieve the passwords and keys from the server.[/quote]Well, that someone probably cannot. :) BNLS doesn't log any of that data, and the only other way to capture it would be by doing a wire capture of the inbound traffic. Given the volume of data that the vL server moves (BNLS, botnet, TeamSpeak, etc.), doing a wire capture is not fun. I wanted to do it once to try to debug some strangeness with one of our other services. It did not go well. :)[/quote]Ethereal filter, ((tcp.port == 9367)). You've got the BNLS traffic. Nothing more, nothing less. =)[/quote]

You completely missed the point of my post.  Finding a particular event is easy, if you're willing to incur the overhead of capturing all the junk that's coming through the box.  Even using a capture filter instead of a display filter, there's overhead associated with capturing all the packets just so they can be discarded.  My point was that trying to run a capture on a serious production box (particularly a Windows-based one that doesn't even have decent capture tools shipped with the distribution!) is a nuisance, not that it cannot be done.

If you're worried about it, there are numerous methods of using BNLS functions to not have to use hash files while not sacrificing security: BNCSutil. Hash the information and send the hash information to BNLS and all is well providing someone doesn't try to brute your hash. At least it's harder. :D

This whole topic was just to prove a point to someone, I wasn't trying to down the BNLS server, I use it, I like it, I always have.

If you already knew how BNLS functioned, why make an entire thread asking the question? It's been covered many times in the past.

BNLS is just one of those things you use at your own risk.  Whether or not your information is stolen, the responsibility still lies with the user.  You must remember BNLS is a free service.

And it's already been stated before, it's just silly to do anything besides checkrevision remotely...

In all the years BNLS has been running, I am unaware of a single security breach, or even an unsupported complaint of one.

I've heard of security breaches, but they were by good-willed people and no information was stolen, and the holes were fixed.

In the BNLS service application?

Yea, I recall UL found a buffer overflow that let him see people's information, I assume it was information currently being processed.

Yes, this is true and I reported it right to Skywing & IIRC Kp at the time it happened.  I don't think I will go into details though ;)

It wasn't a buffer overflow.  UserLoser broke protocol and the server happened to try to answer him instead of just killing the connection on principle.  The disclosure was fixed very quickly, and I think BNLS now kills connections which violate protocol in that way. :)

Er, didn't see his post about the buffer overflow.  Yeah it wasn't a buffer overflow, I just did something when you were not supposed to and it let me...like Kp said