Win a copy of OCP Oracle Certified Professional Java SE 11 Programmer I Study Guide: Exam 1Z0-815 this week in the Programmer Certification forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • Devaka Cooray
  • Tim Cooke
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Ron McLeod
  • Carey Brown
Bartenders:
  • Paweł Baczyński
  • Piet Souris
  • Vijitha Kumara

Messaging app design

 
Al Hobbs
Rancher
Posts: 506
6
IntelliJ IDE Spring Fedora
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi all,

I am planning on making a phone messaging app for fun.  I was thinking I would use a publisher subscriber design for it.  I figured that way having multi person chat would be simple.  

Is there another design that might be better?  

Thanks
 
Tim Moores
Saloon Keeper
Posts: 5881
147
Android Mac OS X Firefox Browser VI Editor Tomcat Server Safari
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That seems not quite the right paradigm - one doesn't need to subscribe to anything in order to receive messages. For a group chat, yes - one needs to sign up to it, or be signed up by someone else who is allowed to do that.
 
Al Hobbs
Rancher
Posts: 506
6
IntelliJ IDE Spring Fedora
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok a 2 person conversation seems like you would only need the ids for the people.  Then pub sub for multi chat.  

I was planning on having the connections all be ssl.   For authentication I was planning on having unsigned longs point to authentication data in a database.  

Is that idea feasible?
 
Stephan van Hulst
Saloon Keeper
Posts: 10783
230
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What do you mean by the authentication bit?
 
Al Hobbs
Rancher
Posts: 506
6
IntelliJ IDE Spring Fedora
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van Hulst wrote:authentication bit?


For example,  in oauth protocol (?),  a user sends his password one time and then the next time the user sends a request with a token that can be verified on the server side.   The idea being that if the request is comprised they only get a temporary token instead of the password.

I want to do something similar but instead of sending a token it would just be an 8byte number.  

My goal was to have the messaging done with very little over head in an ssl stream.
 
Stephan van Hulst
Saloon Keeper
Posts: 10783
230
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And what if a malicious user just sends a random number to your server to authenticate their request with?

There's a reason that authentication tokens are very long and very random looking.
 
Al Hobbs
Rancher
Posts: 506
6
IntelliJ IDE Spring Fedora
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The number would be the id for a database entry that has the user ID, expiration etc.  If somebody sent a random number then it would close the stream I guess cause it wouldn't match
 
Stephan van Hulst
Saloon Keeper
Posts: 10783
230
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry, I should have said 'number of their choice', not 'random number'.

If I'm out to steal your user's private information, what would stop me from forging a request by authenticating myself with the ID '1' and get the first user from your database?

Even when you use random IDs instead of auto-incrementing ones, an 8 byte ID is MUCH easier to brute force than a 400 byte token string.
 
Al Hobbs
Rancher
Posts: 506
6
IntelliJ IDE Spring Fedora
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I forgot to mention that the user id would be sent with the 8 byte number if that makes any difference. if authentication fails too many times I could block the IPs / lock the account. Not sure if that works, but I would try to have some kind of mechanism for defending that kind of attack.

I would try to have the user ids auto increment but I would try to start it from a higher number.  I guess somebody could just guess a high number.

When you say brute force the id you mean like brute force unencrypting an intercepted request or just sending a lot of requests to the server?
 
Stephan van Hulst
Saloon Keeper
Posts: 10783
230
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I still don't know what you mean. In an earlier post you said you want to send a user ID as an 8 byte number, instead of an authentication token. The entire idea behind an authentication token is that it has no meaning, it can not be traced back to a user except by the issuer, who keeps a mapping of tokens against user identities.

As soon as any authentication token that you send caries meaning, such as "row number in a table", you've already lost the security game. Consider this: an attacker might first create a new account, figure out what their own ID is, and then forge requests using a couple of IDs that are a bit smaller than their own. Don't underestimate how creative hackers are in circumventing whatever tricks you might throw at them.

Security is easy to get wrong. Why not rely on the solutions that have already been written by the experts, and perfected over the years? If I were you, I'd either go the single sign-on route and let a third party identity provider (Facebook, Google, ADFS) handle my access tokens, or I'd setup my request pipeline with pre-written authentication middleware.
 
Al Hobbs
Rancher
Posts: 506
6
IntelliJ IDE Spring Fedora
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What I meant was when the user connects to the server they would authenticate themselves by sending their user ID and the token.   The token would be looked up in the token table and then it would check if the user id associated with the token matches the user id sent in. The token number would be random.   They would have to have the user id correct and have the token correct to get in  .  It would basically be basic authentication except the password is temporary and has limited privileges.   Essentially the user sends his id (auto incremented 4 byte number) along with a 'token' (random 8 byte number).

I still could use single sign on to handle my authentication which would be better I agree.  Even if the token size was 800 bytes it would be sent only when the connection is first made because the connection would be maintained for a while unlike http.  The problem that I have with sso is that it would make it much more complicated.  The pro about sso is that I would be able to use a service that requires a phone number.

Is it still possible to use single sign on with that kind of connection? Or would they have to do the oauth dance before making the connection with their new token from Facebook?

 
Stephan van Hulst
Saloon Keeper
Posts: 10783
230
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Al Hobbs wrote:What I meant was when the user connects to the server they would authenticate themselves by sending their user ID and the token.


I assume you mean when you first set up a TLS connection. How would the client know what token to send before they established connection? If they get the token in a separate TLS session, when is the token invalidated?

The token would be looked up in the token table and then it would check if the user id associated with the token matches the user id sent in.  The token number would be random.   They would have to have the user id correct and have the token correct to get in  .


Sending the user ID is redundant. Once the server has issued a token, they know what identity the token belongs to, and the client need only send the token, not the ID.

It would basically be basic authentication except the password is temporary and has limited privileges.   Essentially the user sends his id (auto incremented 4 byte number) along with a 'token' (random 8 byte number).


Look at it this way: Why would you send a 4 byte number that has a specific meaning along with an 8 byte access token, when you can just send a 12 byte access token instead? Much more secure, using the same number of bytes.

I'm curious, how did you arrive at 8 bytes in the first place? What made you say that 8 bytes is secure enough, and 400 bytes - or even 16 bytes - is too long?

Is it still possible to use single sign on with that kind of connection? Or would they have to do the oauth dance before making the connection with their new token from Facebook?


You can't make your own UI to ask for the username and password, because that is diametrically opposed to what OAuth is about. Instead, you need to use a library that is provided by the third party identity provider. For instance, if you want to use Facebook as your identity provider and your client runs on Android, you can use the Facebook SDK for Android. You tell it that you want to authenticate the current user, it starts up a new activity that allows the user to enter their credentials, and when it's done you get an access token. Then when you establish a connection with your server you send the access token to your server, which validates the access token with Facebook and uses it to get the user ID.
 
Al Hobbs
Rancher
Posts: 506
6
IntelliJ IDE Spring Fedora
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Stephan van   wrote: How would the client know what token to send before they established connection?


If they dont have a token to use then they would have to send their username and password to get the token.  I guess I would invalidate it after a certain amount of time.  Maybe id do amount refresh token and access token kind of deal.


Stephan van   wrote:
Sending the user ID is redundant.


Yes I was thinking that because guessing the 8 byte number might be too easy.

Stephan van   wrote:
when you can just send a 12 byte access token instead?
I'm curious, how did you arrive at 8 bytes in the first place?


8 bytes came from an unsigned long being 8 bytes.  I would just convert the bytes.   I realize now that should probably just make the token longer.  
I was thinking maybe using this:
https://docs.microsoft.com/en-us/dotnet/api/system.security.cryptography.randomnumbergenerator.getbytes?view=netframework-4.8#System_Security_Cryptography_RandomNumberGenerator_GetBytes_System_Byte___

The question I have now is if I have a longer token, how long is enough  to be secure but not too long like 600 bytes.


Stephan van   wrote:
use the Facebook SDK for Android.


I wasnt actually going to use Facebook but if theres a library that handles of that for you then that seems pretty easy and might just do that.   I will have to look into the one that I want to use.
 
Look ma! I'm selling my stuff!
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!