35

No, this doesn't seem secure. Collisions Mersenne Twister is a deterministic RNG, so it's not suitable for most cryptographic tasks (although it's usage makes sense, because if it weren't deterministic, your approach would of course not work). In this case, collisions would not happen at the stage you assume and base your calculations on. Instead, they ...


21

If it is not secure, are there any better alternatives? It's secure for certain threat models, and the best tradeoff for accessibility vs attack surface. To intercept an SMS, you have to have some control over the routing of the messages or the device receiving it. Without privileged information / insight provided at the carrier level, SMS is the best ...


18

Originally this question wasn't about SMS verification (e.g. for password recovery or MFA), but validation of the phone number. This answers to that question. The purpose of the verification is not to validate ownership of the number, but only access to it. Verifying the ownership of a subscription would be a legal thing and require legal documents. Parents ...


13

There is sometimes a trade-off between security and usability. If it's important to you or your users that other people don't know they're using the site, then your second choice is the best one. You can always send an email to an address that doesn't exist in your system, like "Someone requested a password reset for this address, but it's not in our ...


12

It depends on why you want to confirm an e-mail. If that e-mail will later be used for password reset, the proposed workflow has a major security problem. Consider the following scenario: Alice creates a new account and inadvertantly write Bob's mail (say she copy-paste the mail and uses wrong line) evil Bob sees the mail, confirms the account, writes down ...


10

The email harvesting scenario you describe is really slow and not likely to happen, at least as a way to gather lots of email addresses. The attacker would need to brute force really long strings against your form. As already stated by symcbean, emails are already very cheap if you buy them and it's pretty easy to block such attempts if someone tries to use ...


8

Should user invite links expire at all - if so, what would be a good expire time? That is a question that doesn't have a general answer: it depends on the value of the resource you're protecting, who are the people receiving your invitations, how secure is the channel you use to transmit these invitations and what are the threats you're trying to protect ...


7

If you allow any sequence of bytes as an username, you'll get a lot of possible problems users can abuse, and other issues: For unicode, the same character sequence can be represented as different byte sequences. You'll have to do Unicode normalisation in order to get at least some security against people being able to register another byte sequence ...


6

You start with a username + password hash, with the latter hopefully being a cryptographic hash with at least 256 bits. Then you turn it into a 10-digit number, throwing away all but 33 bits. You then use this as a seed for a pseudorandom number generator to compute a 48-bit key of words, but the information is already lost -- you can't stretch 33 bits into ...


5

Email Verification First If your UX allows, you can require the user to first create an account based on their email address. Once the address is verified you can allow adding a phone number and then verify it your usual way. A legitimate user likely has an email address already, and therefore the setup remains easy. However, an attacker would have to ...


4

If any of your friends have shared their contact details with Facebook, they may well have picked it up from there. It's buried in the terms and conditions that they have on account creation, so it's very easy to miss...


4

Bots are usually made generic. There is no bot to register specifically at Celeritas.domain and post spam. There is a bot to register at any generic Wordpress/xForum/yCMS site and post spam. It is very hard to generically write a bot that can answer "What is one plus -2", "What color is a Firetruck?", "What is the name of this Blog?" and whatever else such ...


4

You are introducing a user enumeration flaw into your system. That is, any attacker can find out if bob@example.com is a user on your system by completing the registration process. This is useful to an attacker for two reasons: As per the article linked above As an attacker if I can use your login or forgotten password page to narrow my list from 10000 ...


4

It's the OAuth 2.0 device code flow. It goes something like this: The device makes a request to the authorization server's device code endpoint The authorization server responds with a code to show to the user and a URL where they should enter that code The device displays the code and URL to the user The device begins periodically polling the ...


4

tl/dr: This company has no idea what they are doing. If you want to protect your data, the only option is to refuse to do business with them. Privacy and HTTP The first question is whether or not it is possible to communicate privately over HTTP. The answer is generally a solid "NO!". HTTP is a plain text protocol, which means that every server ...


4

Consider counting only business days If you're worried about vacations and holidays, consider excluding weekends and holidays from your counting. This might be difficult if your users are spread across different nations, but I think there's value in counting business days rather than standard days. Ten business days is three weeks, which should be pretty ...


3

If you're ever able to "send back" the password, through any channel, then you're not handling passwords correctly. Period. If the password can be retained in the form via client-side caching, that's perfectly fine. Arguably still riskier than not, but certainly much safer than: (a.) sending the password over the wire (in any form) more times than necessary,...


3

From a security standpoint, I can't see any problem with this flow. It actually may be more secure than requesting user details and then verifying the email address. A user could enter an incorrect email address end end up giving access to their account to a random third party. In your scenario, there is no account to access. You will have the possibility ...


3

Aside from mathematics, your system is insecure due to user assumptions. Ordinary users do not generally treat their username as a secret. Most systems do not hide it from other users (e.g. on this very site we can all see each others user names). Your users will have no inclination to not sharing it, and will not understand that you are logging them in ...


3

No, you have not eliminated the password. You have eliminated the username, then renamed the password as the "username". Since you are calling it "username", your users will assume "this is my username, I can share it online with my friends", and boom their account gets hacked. Do not make security rely on the secrecy of a "username".


3

Anybody can see new domain registrations, at least in mainstream extensions like .com/.net/.org. This is public information and you could even compile this data for yourself using zone files. You can even apply for zone access straight from the registries. Example: Verisign TLD Zone File Access Program. Note that the rules vary from one extension to another. ...


3

What are some attacks that a hacker could do to take advantage of a registration setup such as this? Although this will most likely not help you in your case to change the registration flow, the first thing that comes to mind is to abuse the SMS function. Since only a username and a phone number are required this can be used to: Get the company out of SMS ...


2

The answers so far are good but it's important to note that from a profiling point of view- I don't care if I don't get in to their account but the knowledge they're using a service is enough to social engineer a situation/monitor their social feeds for potential passwords (pets, kids, cars etc). That being said, during user signup it would be a bad UX ...


2

So I guess as a primer we need to consider what an attacker can actually do if you confirm / deny existence of an email on your system in some easily accessible way. This is a possible scenario: An attacker has gained access to a database of compromised email addresses + passwords. (i.e. they can log into any of these user's emails) They want to gain access ...


2

First off, if we're talking about a website, the idea of having a public API which is used to create users seems strange to me. Usually an account is manually created by the person that wants one, perhaps using a web page, and perhaps with a captcha. The ideas of API and captcha don't really go well together since APIs are called by Applications (thus the A ...


2

You could use a tool like Fail2Ban against the API logs to block an IP for 5 minutes (or whatever you want) after 3 (or any number) of account creation attempts. http://www.fail2ban.org/wiki/index.php/Main_Page It would also be wise to know some common API requests that are made by brute force attempts that do not exist on your site and automatically ...


2

Annoying, isn't it? Security and usability are often at odds. In this case, the risk is pretty small, but it's there. Imagine the following: You enter all your info, including password, and submit You temporarily lose your wifi connection, or something happens on the 'net to cause the response to be incredibly slow Losing patience, you walk away from the ...


2

This is not a problem in itself, but in my opinion a web application should implement the policy that passwords are only input, never output. Following this policy will result in a much more secure system as far as handling passwords is concerned. If you are going to do this, then make sure you set the appropriate headers to prevent caching in the browser ...


2

It depends if the registration form contains any sensitive data and if the newly created account may be of any value to a third party (either by itself or by impersonating the legitimate user). The issue is that if the user made a mistake while typing his email address, the registration link may be sent to an unknown person. In the proposed registration ...


2

With your "Proposed Registration flow" you are assuming the person that has just made the account is the person that clicks the link. This assumption is generally true and there are people out there that will just take this risk. Afterwards this is an issue of what balance you are looking for between security and usability (quite an interesting debate ...


Only top voted, non community-wiki answers of a minimum length are eligible