ASSS ChatNet update

[Cheese]

plus, if the biller isnt exposed to anyone, and the only things that can interface with it are zones, theres essentially no risk, as a compromised zone doesnt have enough information to crack anything

and what im envisioning is a pure distributed system where any zone could be attached to any biller, and your suggestion directly translates into any number of key servers attached to every biller

and then you get the problem of potentially malicious rogue key servers

[JoWie]

That's the easy part. Signups and password changes are only allowed through the (hypothetical, remember) online interface. No zone involvement at all, so no trust issues. Doesn't have to be connected directly to the biller (or even be hosted on the same box), but it would need database access.

 

But this online interface would need some encryption as well, otherwise your password would fly in raw form over the network.

This would require asymetric encryption, very likely in the form of https (TLS).

Now if you have https, why not implement every part using https. All you need to do is distribute Certificate Authority keys with the client (which you do not need to change if a new biller is added with different keys), or use the ones that come with the operating system.

 

This would also take care of the database leak issue, the client connects to the biller on his own.

If you use a very strong method of storing password in the database like scrypt (a very interesting one, it is much harder to parallelize), even if you leak the database you would not be able to login as any player (provided they had chosen a strong password) with a modified client.

 

This is my reasoning for preferring a system that is similar to openid.

[Dr Brain]

Obviously the website would use HTTPS, but it's far easier to create a website than it to use TLS and some zone tunneling system to get the biller and client to talk directly. Plus you have to figure out how to get the info to the zone, which is an extra complication. There's also the question of what >5000 open TLS sockets will do to a billing server. I shudder to think.

 

It could be made to work, of course, but the scheme I proposed has the advantages of being (relatively) simple, not requiring public key distribution, and working with UDP based protocols like SS currently enjoys.

[JoWie]

What I envision is that the auth service is _only_ a website. Everything is https, all connections are short lived. Points, chat, banning, whatever is not part of this auth service. This scales out (instead of up) very easily

Setting up such a service is probably a days work.

 

Note that I am ignoring any existing architecture in these ideas. This is mainly because I do not believe in a drop-in replacement (like mysql & mariadb) for continuum (or at least, not worth the effort required)

[JoWie]

This one is interesting: http://srp.stanford.edu/design.html

It does not require storing plain text in the database. And all you need is a hash function and a secure random number generator.

 

C lib: http://code.google.com/p/csrp/

[🜲 Vidiot_X]

Hi,

 

I was just cruising by and thought have you looked at Blowfish as an encryption method for passwords?

 

- Rich -

[JoWie]

Hi,

 

I was just cruising by and thought have you looked at Blowfish as an encryption method for passwords?

 

- Rich -

 

Do you mean bcrypt? Yea i've seen it, I have actually mentioned one that is very similar in this thread, scrypt.

Scrypt has an advantage over bcrypt, you can also vary the memory that is needed to take a guess. This makes it much harder to parallelize.

The downside of scrypt is that it has been researched a lot less. bcrypt has been around for a while. There is a bitcoin alternative that uses scrypt though.

Edited October 22, 2013 by JoWie

[Dr Brain]

This one is interesting: http://srp.stanford.edu/design.html

It does not require storing plain text in the database. And all you need is a hash function and a secure random number generator.

 

C lib: http://code.google.com/p/csrp/

 

In my opinion having to store passwords in cleartext on the client side (or not storing passwords at all) is unacceptable.

[Cheese]

agreed

[JoWie]

 

This one is interesting: http://srp.stanford.edu/design.html

It does not require storing plain text in the database. And all you need is a hash function and a secure random number generator.

 

C lib: http://code.google.com/p/csrp/

 

In my opinion having to store passwords in cleartext on the client side (or not storing passwords at all) is unacceptable.

 

 

p could be another hash. Just like the method you posted earlier. The database would then need to store x_plain and v_plain and x_hashed and v_hashed Web interface would use the first two, client authentication would use the last two.

Edited October 24, 2013 by JoWie

[X-Demo]

I've committed my changes here: https://bitbucket.org/X-Demo/asss.

 

I'll be making the pull request to grelminar/asss shortly...

 

P.S. Thx for hijacking my thread, pfft!

[X-Demo]

Numpf took a quick look at the pull request!

 

https://bitbucket.org/grelminar/asss/pull-request/1/chatnet-websocket-ssl-support/diff#comment-1335052