Re: Email addresses in URLS?

On 24/04/2022 10:46, Narcis Garcia wrote:
> __________
> 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.


I might not limit the token use to the specific IP as that could cause 
issues for users who, for example, sign up on a desktop but receive the 
email on their phone, which could result in different external facing IP 
addresses if the two devices aren't on the same network. But it can be 
used in conjunction with other things to detect malicious behaviour. For 
example, if the same IP seems to be registered against a lot of signups 
within a given time window, it could be sign of a bot.

Obviously, you might not need to go this far into analysing things, it 
really does depend on what your site/app is doing, and whether it's 
worth investing that sort of time into that level of security.

-- 
Ashley Sheridan
https://www.ashleysheridan.co.uk