SignUp on HTTP

warleyalex · 2016-09-27 13:55:05

Hi everyone, sorry the ignorance,

I want to provide a server where anybody, via a web interface on HTTP, can register a new user.
Afterwards, the user will log in with his registered user name, and from here, all operations will be done logged in.
Since I am using a web interface for everything, I am going to use only the interface-based services as the interface
with the server. Internally, these services will comunicate with the database layer to perform whatever.

About the security, everything must be secured (using the framework security options), but the registration of a new user, which, since there is no user yet, it cannot be secured.

To allow the users to register a new user without security, I've created a "signup" method, this is actually
By Pass Authentication method in order to by-pass of the RESTful authentication scheme.

So, the app encodes a message with AES-256 and passes it to a server via AJAX. Then the server and decodes the message with SynCrypto.

I'll encrypt/decrypt the message with the "same key", the initialization vector (iv), would be dynamic, generated from the server, with a random 16-byte. Actually, the random IV is public.

for instance:
------------
At the client, onClick "Register" button, the public method genIV will be envoked:

I'll get the response of
POST http://localhost:8080/root/MyServiceFree.genIV --> response {"iv":"6e77e69599bf7401c63efebe449750f4"}

...and using CryptoJS AES-256 to encrypt the user info:

{"user":"warleyalex", "password":"abcd", "email":"abc@.com"}

On submit "form User registration":

POST http://localhost:8080/root/MyServiceFree.SignUp
{ "ciphertext":"48CFbqo+igV2FYcqD40aJ5C1P8DmZrlNIXp4W76zNftWSoRDOfU45aC8l5jtFORi
6FsW5IkkWJ4xvTUVirbJyA==" }

At the server, the problem is the server entity which will decrypt the message must know the generated IV "6e77e69599bf7401c63efebe449750f4".

Any hint?

oz · 2016-09-27 16:08:11

Maybe I got you wrong, but you said the IV is generated by the server, so the server already knows about the IV. Doesn't it? Why are you encrypting that thing at all? Is it about transport layer security?
Maybe you could explain in more detail...

warleyalex · 2016-09-27 17:55:23

Apologies for my ignorance, this is simply a javascript callback . Thanks!

ImproSnake · 2018-01-22 10:18:04

Hello,

Sorry for reviving this old Thread, but i am wrapping my head around this for quite a while.

I have a similiar Problem here.

I want to give the user the possibility to register himself at a Webapplication written in Angular.

So i want to do the following based on your suggestion :

Ask the Server for a IV and get this. This is an easy to solve Problem.

The Client takes the IV and encrypt his credentials (as far as you stated).

But if the Client sends the Cypher to the Server, how does the Server know the IV for this specific Client ?
We have no session cause we dont called the Auth yet.

In my Opinion, sending the iv back to the Server in the Client Response breaks the Security.

How does the Server know the IV for every specific Client if they arent authenticated yet ?

Saving the IV and a ID in a Database temporarily semms wrong to or ?

How can we achieve this ?

Maybe i cant see the forest for the trees here and the solution is quite simple.

Thank you guy's for your help.

Last edited by ImproSnake (2018-01-22 10:22:40)

ab · 2018-01-22 14:53:21

Both the client and the server have a nonce (what you wrongly call an IV - and there is no encryption, just digital signature using the nonces/salts).

edwinsn · 2018-01-23 06:14:52

I think the so-called initialization vector or nonce or salt, since it's already being sent to the client in plain text, when posting back to the server, just include that salt in plain text would be ok.

ImproSnake · 2018-01-23 06:51:43

Hello Guys,

thank you for your help.

I will rethink the Process. Thank you for your information & ideads

mORMot Open Source

#1 2016-09-27 13:55:05

SignUp on HTTP

#2 2016-09-27 16:08:11

Re: SignUp on HTTP

#3 2016-09-27 17:55:23

Re: SignUp on HTTP

#4 2018-01-22 10:18:04

Re: SignUp on HTTP

#5 2018-01-22 14:53:21

Re: SignUp on HTTP

#6 2018-01-23 06:14:52

Re: SignUp on HTTP

#7 2018-01-23 06:51:43

Re: SignUp on HTTP

Board footer