Re: Email addresses in URLS?

__________
I'm using this dedicated address because personal addresses aren't 
masked enough at this mail public archive. Public archive administrator 
should fix this against automated addresses collectors.
El 24/4/22 a les 11:36, Ashley Sheridan ha escrit:
> 
> On 24/04/2022 06:40, Aziz Hussain wrote:
>> You can skip the DB part by sending the email address encoded and you 
>> decode it when they click. You can use a custom key so it is unique to 
>> that application.
>>
>>> On Apr 24, 2022, at 1:24 AM, Stefan A. <[email protected]> wrote:
>>>
>>> 
>>> I don't think it's a good idea to expose email addresses like that. 
>>> In between the user who clicks on the url and the server that hosts 
>>> your application the request can pass through many other servers. You 
>>> don't know what they log and what they do with those logs. So 
>>> probably best to avoid doing that.
>>>
>>> I don't know the details of your application, so I can't say if a 
>>> MySQL database would be best for you or not, but no matter the 
>>> storage of your application you can avoid exposing email addresses in 
>>> your email confirmation URLs. One solution is to keep an is_verified 
>>> flag on your user entity. The user is created with that flag set to 0 
>>> (in the registration step). You can then generate your confirmation 
>>> email url by generating a signature by hashing the combination user 
>>> id and email.  You put both the user id and the signature in the url 
>>> (something like 
>>> https://your.application.com/userId=1&signature=a012b345c678d9010123456789 
>>> <https://your.application.com/userId=1&signature=a012b345c678d9010123456789>). 
>>> Then when this request hits your application, retrieve the user by 
>>> its id, generate the signature from id and email and compare with the 
>>> signature in the url. If they match, update the user is_verified flag 
>>> to 1 and save the user to storage.
>>>
>>> On Sun, Apr 24, 2022 at 5:21 AM <[email protected]> wrote:
>>>
>>>     Hello. I'm wondering if you can assist with advice regarding
>>>     passwords/hiding emails.
>>>
>>>     basically,
>>>
>>>     a) a user enters their email address
>>>
>>>     b) I generate a code for login and generate an email.
>>>
>>>     c) the email contains the URL to log in
>>>
>>>     http://website.com/login?code=EMAILADDRESS-GENERATEDCODE
>>>
>>>     When the person clicks on it, I separate the email address - and
>>>     generate a new code - if it matches, they are logged in.
>>>
>>>     MAIN CONCERN - is if I have an email address in the actual URL,
>>>     it may
>>>     be easier for spammers to pick it up & start spamming the user.. 
>>> (I'm
>>>     not doing the spamming)..
>>>
>>>     Is that a real or imaginary concern? would the ISPs be spamming
>>>     folk &
>>>     scanning for URLs that pass through their servers for email
>>>     addresses?
>>>
>>>     Would a MySQL database be best - to store email addresses & assign a
>>>     user number for each email? Then use the user number in the URL?
>>>
>>>     --
>>>     Gordon.
>>>
> The best way to do this in my opinion is to generate and store a token 
> on the server, and use only this in the email link. This ensures that:
> 
> * There's no way the email address is leaked or stored in between the 
> user and your servers
> * The token can be limited to a specific time since it was generated, or 
> limited to a specific number of uses
> * You can potentially match the users IP against both the initial sign 
> up attempt and the verification email. This can help towards identifying 
> possible malicious actions by people
> * Email addresses can also contain many characters which would break a 
> normal URL if they were unescaped

+1
This (complex) token code can be directly a unique session ID, and no 
account ID/address is needed. For this, you should maintain a sessions 
table with internal data: Session ID, Account, Client IP, session 
renewed (date&time) for expiration, and even session data if you prefer 
to not load user with cookies.