78
What I see most commonly is allowing the authentication and signing the user in, but locking meaningful features away until the email is verified. You should bubble up an error reminding the user to re-send an activation email if they try to access one of the restricted features.
It is poor design to ever lie to a user - if they submit the correct username ...
30
If you ignore the certificate warning the encryption still applied, but because it's an unauthenticated encryption, the encryption is useless against active adversary (an MITM adversary that can intercept and modify the data passing through it), as the active adversary can just reencrypt your connection.
The best practice to use self signed certificate in ...
16
Yes, the communication is still encrypted with self-signed certificates.
Self-signed certificates can be made by you, but they also can be made by any attacker. If you insist on using self-signed certificates, I would advice you to mark the certificate as trusted, so that you get a warning if an active man-in-the-middle attack is happening.
Creating your ...
8
I agree with Buffalo5ix, but email verification should not be considered a part of account security. Email verification:
proves the ownership of the address, just to know that the user has entered correct address for you to send spam password recovery emails.
serves as a very light deterrent for registering multiple fake accounts. It's pretty easy to ...
7
You don't want to leak the information that the username exists in response to an unauthenticated login attempt. That would allow attackers to determine which of the email addresses on their list exist with your service.
But if the user logs in with the password that they supplied upon registration, that's not the situation you're in. You know (as much as ...
5
Cryptography has three main security goals:
Confidentiality
Integrity
Authentication
The certificate in the TLS/SSL handshake is used to provide authentication, i.e. to guarantee the client that he is talking to the intended server and not some Man in the middle attacker. Ignoring a certificate warning will kill this property of the connection.
The ...
3
Let me just draw a MITM for you.
===| When you accept a self-signed cert |===
===| and get lucky |===
+--[Your browser]--+ +--[Server S]--+
| accepts cert A | | has cert A |
| sends +---------------------+...
3
Encryption is still applied, the issue with self signed certificates is that you have no assurance that the server you are connecting to is who it says it is.
The problem is not so much that they are self signed, it's that they are not signed by some third party you trust. When you browse to a https website your computer checks that the certificate you are ...
3
The overall goal is to verify that a user can be reached through the email address.
This is done by creating a token, and any way of delivering that token back to your server will do, whether it is having the user click a link or copy/paste (or retype) a code.
Since your list includes password resets and email resets as reasons why you might send a token, ...
3
What are the downsides? None, really, aside from significantly increased complexity1, which is rarely a good thing, as well as high migration costs for literally every website with a password field, which is also not a good thing.
But let's consider the implications anyway, to see if they outweigh the costs. There are two ways you could handle this hash:
...
3
This is wrong. A sysadmin should never log in or even know the users password in the first place.
The issue is with the system, fix it. A good pitch to the management to get $$ for the fix is to say that this impacts your security very badly and give him a good example of what could happen if let's say a sysadmin goes rogue + how much it would cost them.
2
Yes, cross signing is possible.
What you need to do is let A sign a CA certificate which
uses the same key as B
uses the same subject as B
(and vice versa). If those intermediate certificates are made available, then there are two possible chains for each end entity certificate signed by either A or B which end in either of your roots.
2
Can someone explain how this was possible
It was possible due to a lack of rate-limiting on the action/request. As you said, it could be brute-forced hence.
Instagram has now patched this issue. I haven't seen any official publication on the mitigation measures, but a quick visit to Instagram's Password Reset Page reveals the [intended] user is now sent a ...
2
You should transfer the password over HTTPS. For storage, hash the password with Argon2.
Do not attempt to roll your own scheme. Anything beyond the above is generally unnecessary except for specific circumstances (e.g. where you need the server to have no knowledge of the password, in which case you want SRP).
1
For me it was a matter of how efficient the verification process was and how well it actually worked in practice.
[ verification code ]
can be generated with the specific complexity you need/want
will most likely reach target
can be protected itself in various ways from interception (like being sent as a small picture or even as a blurred captcha-like ...
1
tldr: The approach you outline fails do address the actual problem, use a separate application and a secure authentication scheme.
While you are right that keeping account credential information with the rest of the lot (i.e. whatever your application actually uses when it's not authenticating users) is a bad idea (tm), the approach to just have a second ...
1
I'd like to point something out that is perhaps being overlooked
Should the error message say "Your user name or password is incorrect?", instead of letting them know that they have forgotten to verify the account.
I assume this is the most secure way of handling it, because if we tell them that they have to verify the account, we are letting them ...
1
This is a reasonable idea, but there are some problems with coordinating massive centralized efforts. KOLANICH already suggested SRP, very nifty and even more secure protocol for remote passwords.
The main problem is that very few people actually care about security to force whole IT industry to change what's already working. Meanwhile privacy freaks can ...
1
I'm not seeing the risk in this process. You test all accounts that have been created by this process, and either:
Truely new accounts successfully log in, and the only thing exposed is the data that was used to create the account. This info was the same as the data that the admins used in the account creation process. Nothing new has been exposed.
...
Only top voted, non community-wiki answers of a minimum length are eligible
