Do I understand how the token?

write rest api. All users have a unique token. With the mobile app I send the login and password to the server api. After all if it is true, I give the customer this unique token, and as a mobile application spa, save it in the document. And make all requests using this token, the server checks if it exists, given the data.
July 8th 19 at 15:25

Related questions

More answers about "Do I understand how the token?"
2 answers
July 8th 19 at 15:27
Solution
Yes. All right.

The only thing I will add, to forward the token in the headers. Preferably, since the authentication mechanism is non-standard in the header X-Authorization. If you decide to store the token in a cookie and pass it, it should be http-only cookies (although in the case of JWT do not have) and the server should be protected from CSRF attacks.

As well as we walk through the network in fact credencial, it is important to use SSL. Fortunately today there is a lets-encrypt that would be free to obtain certificates.

And the last thing to protect yourself is use refresh-tokens. That is our unique token which walks each request will have a time limit of life (say 5 minutes) and to update it we will use the refresh token. When you receive a refresh token the client gets a new pair of token + refresh token.

Thus the attacker who intercepted the user token window is only 5 minutes to do something.
headers of the form X -*, like as in deprecate not? - kavon.Murphy commented on July 8th 19 at 15:30
: Yes, but tell that to Apple and their guidelines. They absolutely insist that it would be for a custom authentication used X-* headers, because the default Authorization can be overridden by the system.

In General, RFC 6648 Lee says that this is not recommended but not prohibited. - Allene_Crona78 commented on July 8th 19 at 15:33
: I do not argue, just clarification. thank you. - kavon.Murphy commented on July 8th 19 at 15:36
I write mobile and amazing, simple with phonegap. In the header where to store, if in the meta tag? And that you have to update the token, i.e., again will ask for authentication? - stephany3 commented on July 8th 19 at 15:39
in your case you need to store in localStorage. Given the fact that you were going to store in the meta tag - I recommend you understand in more detail what and why. - Allene_Crona78 commented on July 8th 19 at 15:42
Yes, but phonegap can't be stored in localstorage. And now I test sending data with the mobile application, there are plain html, js, css. Cross writes error, how to deal with it, if the app will run locally on the phone - stephany3 commented on July 8th 19 at 15:45
: cordova knows how to store in localstorage, phonegap would not be able to? - ola_Lueilwitz commented on July 8th 19 at 15:48
: How to deal with Uncaught SyntaxError: Unexpected identifier? The server sends, but js gives this error - stephany3 commented on July 8th 19 at 15:51
: well, on this error without a code is not clear) - ola_Lueilwitz commented on July 8th 19 at 15:54
See, when authorizing, if not true, the server sends a simple string, that user no, everything is OK, the client receives the message, but the console displays an error Uncaught SyntaxError: Unexpected identifier. And the script then fails - stephany3 commented on July 8th 19 at 15:57
open sources in the browser, put a period debarim.. look why is there Unexpected identifier - ola_Lueilwitz commented on July 8th 19 at 16:00
can you recommend something to read or a lesson on how to organize a refresh token, and than using it to change a unique token, if he so fabulous, which is given at registration. Thank you - stephany3 commented on July 8th 19 at 16:03
and you don't just token + SSL? - Allene_Crona78 commented on July 8th 19 at 16:06
July 8th 19 at 15:29
I passed by and, like, all right, except:
With the mobile app I send the login and password to the server api.
Never! You Hear That, Carl?! NEVER SEND the authorization data to the server WITHOUT PRE-HASHING on the client side, the server key.

1. The data on the client: hash(USER1:PASSWORD:SKEY:RANDOM),
2. Send to the server: ab1e37ab50c61d8c80fb5cb4b1e3122f:RANDOM
3. Looking for on the server match:
ab1e37ab50c61d8c80fb5cb4b1e3122f===hash(USER:PASSWORD:SKEY:RANDOM) and get uchetku user, if everything is correct.

And so, Yes! Thanks, all quite clearly and correctly written!
I understand that md5 here as an academic example, but still, it is not necessary even in order to show it. - kavon.Murphy commented on July 8th 19 at 15:32
: approx. replace the hash! - Allene_Crona78 commented on July 8th 19 at 15:35

1. The data on the client: md5(USER1:PASSWORD:SKEY:RANDOM),
2. Send to the server: ab1e37ab50c61d8c80fb5cb4b1e3122f:RANDOM
3. Looking for on the server match:
ab1e37ab50c61d8c80fb5cb4b1e3122f===md5(USER:PASSWORD:SKEY:RANDOM) and get uchetku user, if everything is correct.

How to get same RANDOM on the server and on the client? - kavon.Murphy commented on July 8th 19 at 15:38
: As an option to generate it using https://ru.wikipedia.org/wiki/%D0%9F%D1%80%D0%BE%D... - stephany3 commented on July 8th 19 at 15:41
: Ah, Yes... I thought it was just, let me explain: it gives the server when you request the authorization and the validity of his 15 seconds. - Allene_Crona78 commented on July 8th 19 at 15:44
: it turns out the server needs to know the user's password? Somehow non-kosher. - stephany3 commented on July 8th 19 at 15:47
why?! he may not even know the login) the server needs to know only UID=hash(USER:PASSWORD). I do not write the complete formula, and write principle only))) must Think!) - ola_Lueilwitz commented on July 8th 19 at 15:50
in General, a very strange scheme, the client sends the hash, the server should retrieve from the database all the usernames with passwords, calculate the hash for each(USER:PASSWORD:SKEY:RANDOM) and if there is equal sent, then authorize that account, so?
Too many drawbacks compared to a simple transmission of the password over https. - stephany3 commented on July 8th 19 at 15:53
: I was wondering about what disadvantages is there to it? - ola_Lueilwitz commented on July 8th 19 at 15:56
: as I wrote above - the storage of the password on the server, plus the calculation for each attempt, the login hashes of all users is ready to ddos. - stephany3 commented on July 8th 19 at 15:59
: no, if you have a field hash and skey - ola_Lueilwitz commented on July 8th 19 at 16:02
and how fields hash and computed hash skey(USER:PASSWORD:SKEY:RANDOM)? - stephany3 commented on July 8th 19 at 16:05
hash(UHASH:SKEY:RANDOM) SKEY - issued by the server and stored in front of the user. for skey - search and on - verification. - Allene_Crona78 commented on July 8th 19 at 16:08
: yeah, I started, "where did I say that", "that's not what I meant", "it was necessary to guess".
Offer last time, write the paragraphs, starting with the complete lack of identifying information. The comment "what can there be to understand, everything is obvious" I will not even respond, YAP. - Kyleigh_Hills commented on July 8th 19 at 17:08
: so, the client is registered. The server generates a random skey and random1 and sends from the client. The client comes up with user and password, computes uhash1 = hash(user:password:skey:random1) and sends it to the server uhash1. The server writes to the database uhash1 and skey.
The next day someone wants to login as a server will find you need in the database skey?
Let our database recorded the name of the user and the client says I'm the user and want to login. The server finds a database entry with the user name, takes from it skey generates random2, random2 skey and sends it to the client. The client computes uhash2 = hash(user:password:skey:random2) and sends it to the server uhash2. Total the server has the user skey random2 uhash2 what further action servers? - glennie_Mer commented on July 8th 19 at 16:11
And forgot the server has uhash1 in the database. - Kyleigh_Hills commented on July 8th 19 at 16:14
: well I wrote above: "according to skey - search and on - verification. "What's the problem then? - Kameron_Hilpert34 commented on July 8th 19 at 16:17
: I wrote what the problem is. - sibyl_Pur commented on July 8th 19 at 16:20
the server knows skey and uhash are unique. the search is for skey and is only 1 record. Any more questions?! - Kyleigh_Hills commented on July 8th 19 at 16:23
: complete nonsense. uhash for each attempt, the login is different, as it can be used in authentication? Where the server takes the skey, which is searching for? - Kelsie.Purdy commented on July 8th 19 at 16:26
approx. finished. - Kyleigh_Hills commented on July 8th 19 at 16:29
: Yes, great answer, and I waited for "the search goes on skey and is only 1 record, then verification".
All of you understand, clown. - Kelsie.Purdy commented on July 8th 19 at 16:32
: clown one who is not understanding - begins to be rude. Suggest, to just sit down with a pen and piece of paper and that happened to paint step by step and all will become clear. - Kyleigh_Hills commented on July 8th 19 at 16:35
: You first have to set me a question to answer before handing out advice, so you can see what they are worth. - Kelsie.Purdy commented on July 8th 19 at 16:38
makes no sense to say a person who does not understand (or want to understand!) - Kyleigh_Hills commented on July 8th 19 at 16:41
: can't answer, and to admit their mistakes, say so, and not continued his clowning, telling me what I understand and what I want. - Kelsie.Purdy commented on July 8th 19 at 16:44
: approx. propose to move to a constructive dialogue. the state diagram when communicating between server and client in your understanding - in the Studio. I'll have a look and we understand who and where I went wrong. Agree? - Kyleigh_Hills commented on July 8th 19 at 16:47
: I have a state diagram of your scheme painted above and asked where it stops working. Answer them. If your schema got it wrong, write where.
The diagram in the answer works only if password storage on the server. Without sending the login server will need to calculate the hash for all accounts in the database. Further nonsense about "search skey" simply unworkable. - Kelsie.Purdy commented on July 8th 19 at 16:50
:
1. The client and server know the same skey.
2. He is tied to the account at the moment of generation on the server side and its time of formation is also recorded.
3. When it comes to the server hash from the client, the server already knows USER, PASSWORD, SKEY, SKEY_TIMESTAMP (user and password - it is better to store in encrypted form) and he can calculate the hash server-side (for comparison with the client), using RANDOM.
The server goes through not everything, the accounts to calculate the hash for comparison, but only for:
a) specified the maximum possible interval (5-10 sec)
b) in chronological order of formation of the SKEY based on SKEY_TIMESTAMP
In the end, everything works instantly, regardless of the number of users in the system. - Kelsie.Purdy commented on July 8th 19 at 16:53
:
1. The client and server know the same skey.
Do you know where? A divine revelation? So I bought a new tablet, I go to the site want to login, where I take skey?
3. When it comes to the server hash from the client, the server already knows USER, PASSWORD, SKEY, SKEY_TIMESTAMP (user and password - it is better to store in encrypted form)
You tried to claim that the password on the server to store not need? That is one mistake already acknowledged, that's good.

In General, nothing is clear. Write as well as I do, step by step:
1. To initiate a login attempt. At the beginning of this stage, identification information no. That sends the client to the server.
2. The server's response. As finds and creates the server data to answer that serves the client.
3. Here for your scheme on the client, enter the username and password is hashing. Your words are sent to the server only the hash. - Kyleigh_Hills commented on July 8th 19 at 16:56
:
1. "How do you know?" - to guess it, kaneshno, it is difficult))))
EV came you PIN via SMS or code in the link in the mail (two factor authentication).
2. if you do not store the password!)) you can store the hash a bunch of hash(username:password) - this is who it wants))) (most importantly, don't forget to give the user to ask themselves a name: friendly-name, but it is possible and without it, it's ID-shnik output, but it's visually - not convenient)
3. LOGIN: random and hash sent from the client to the server.
4. "As is the data server for the answer?": The sample is sorted by the increase of the elapsed time based on exhibited SKEY_TIMESTAMP: takes from the stack top entry, computes the hash and compares with sent to the client.
5. "About login and password" - yeah, just it's easier for people. it would be possible to enter a tied hash (as I wrote in point 2)
6. "Your words are sent to the server only the hash." - read the response carefully: "2. Send to the server: ab1e37ab50c61d8c80fb5cb4b1e3122f:RANDOM"

Now all became clear?!))) - Kelsie.Purdy commented on July 8th 19 at 16:59
Again, the nonsense began with a bunch of conditions, assumptions and assumptions. It began with the fact that the customer needs to send one hash, over two-factor authorization. If you have two-factor authentication, why further stuff is needed, it is enough to enter come in the mail or sms one-time code.

Actually, from your comments one gets the impression that a real authentication system, you never once did, and argue on the basis solely of their fantasies. - Kyleigh_Hills commented on July 8th 19 at 17:02
: "It began with the fact that the customer needs to send one hash" - this is where is it?! - Kelsie.Purdy commented on July 8th 19 at 17:05
: alas, in the case of javascript and browsers in that not a lot of sense. Server key kept safe will come. But for mobile apps - you can, Yes. - Kelsie.Purdy commented on July 8th 19 at 17:11
: key raspolovinit: half of letter - link with GET request (or PIN from the SMS), half - return from the server when clicking (or entering your PIN in the entry field). In the end, the two halves will be at the customer in different ways and then sahusilawane and to put the finished key in LocalStorage for future use.
Or am I wrong here?... - Kyleigh_Hills commented on July 8th 19 at 17:14
in principle, right... but why do it? SSL + SSL pinning + ordinary digest does not solve this problem well enough? - Kelsie.Purdy commented on July 8th 19 at 17:17
I didn't want to replace something existing and working well (wasn't on purpose), I asked specifically about safe storage... And so - Yes: SSL+digest quite a solve the problem. - Kyleigh_Hills commented on July 8th 19 at 17:20


OAuth Implicit Grant for browser? Where the client client_id, which do not have to hide, and after authentication using the refreshToken.

Or I not about trying to keep holivar? - Kelsie.Purdy commented on July 8th 19 at 17:23
: >> Never! You Hear That, Carl?! NEVER SEND the authorization data to the server WITHOUT PRE-HASHING on the client side, the server key.

And when you register? As the server receives the source data (login, password), then to generate the hashes? - Kyleigh_Hills commented on July 8th 19 at 17:26
personally, I didn't mean this method, in that method, in fact, the delivery of all the key is communication channels and without any client-side scripts. - Kelsie.Purdy commented on July 8th 19 at 17:29
the server initialization procedure registration sends a server key (SKEY) using the hash via two channels to the client.
Then, the server obtains the hash pair from the customer signed by that key and generate a record on the server (i.e., clientID=hash(user+pass+SKEY+RANDOM) and separately sends RANDOM), then you can change a couple of clientID using a previously issued token or refreshToken.
The server never knows separate login and password.
For a visual user display on the page - start field, a FriendlyName and all. - Kyleigh_Hills commented on July 8th 19 at 17:32
: A hash key? From the hash key not pull out, then to do cliendId. Or what do you mean "sends a server key (SKEY) using the hash"?

It can be an example of two channels?

Highly interesting to understand, but yet confusing because of inaccuracies in the allegations. If the server does not know the password/login, from which he generates new hashes? And if you know, how they get to the server and it stores them so? As clienId from the front is found the user on the server? What the system protects? - Kelsie.Purdy commented on July 8th 19 at 17:35
the server knows the key and the pair (username and password) in a single hash, which pereseltsy generated by the key server through the replacement procedure (previously generated by the server). - Kyleigh_Hills commented on July 8th 19 at 17:38

Find more questions by tags LaravelPHP