Re: OTP Verification Issue – Unjustified Closure

[Swi-ft]

Hey,

I just saw that the issue I raised regarding OTP verification has been closed with a vague and completely inadequate explanation referencing “third-party payment flows” — with no proper justification or resolution.

Let me make this absolutely clear:

We have already implemented OTP verification on our own website.

So don't tell me it’s not possible or brush it off under the blanket excuse of "3rd party payment flow constraints." That’s just lazy. If you're saying it can't be done — explain why. Don’t just close the issue without discussion.

If there’s a real technical blocker or design reason that OTP cannot be integrated in the way we suggested, I expect a detailed explanation — not a one-liner.

Otherwise, reopen the issue and treat it seriously. We’ve put time into this, and we know it works.
Looking forward to a real answer.

[harshitptl21]

Read what constitutes a bug and what the testing phase is.

[harshitptl21]

I have reopened all the closed issue. Read them properly.

[harshitptl21]

Issue #7

[Swi-ft]

Please give your proper response here, I have closed #7

[harshitptl21]

This is testing phase, your task is to report bugs. You can suggest improvements if we have to work on next version, which is out of scope of this course. The project is implemented according to the documentations.

The cost of a third-party verification services may not be reimbursed, and free third-party verification services often provide poor service and raise privacy concerns. Developing an in-house verification system is beyond the scope of this course.

Identity verification (e.g., Driver’s License/ID) is an optional field. Users may skip this step if they prefer not to provide an ID, instead of creating fake information. Additionally, using third-party verification services may raise concerns about service quality and privacy, and integrating a secure, in-house solution is beyond the scope of this course.

Addition to the above comment:

Using common passphrases is also insecure, even if they are longer than 8 characters. Implementing a feature that compares user-created passwords against a list of commonly used passwords and then accepts or rejects them based on that comparison—would that be considered a bug or an improvement?

I was referring to the quality and privacy of the third-party free OTP services. Also, does the third-party service you're using guarantee user data privacy?

Besides, this kind of verification was never mentioned in the documentation.

[Swi-ft]

-> "I was referring to the quality and privacy of the third-party free OTP services. Also, does the third-party service you're using guarantee user data privacy?"

Nope, we are using our own OTP generation methods, which is secure. We are generating using cryptographically randomized secure libraries to generate OTP, sending email using google SMTP app based services to send Email. Being a basic version, Gmail detects it as a spam but it is not in case for workplace specific domain, it has a limit of email sending as it was free, but it holds security as google has a no data breach policy for this app password based mailing application.

-> "Besides, this kind of verification was never mentioned in the documentation."
With all due respect, it is a bare minimum for an app in a course-project, which is a intended to be useful for real-world purposes, to have an OTP feature, it shouldn't be something that can be by-passed.

-> "Developing an in-house solution is beyond the scope of this course."
Do note that almost all the groups have implemented this feature and if not, they have been duly told to do so by their respective testing teams.

->"You can suggest improvements if we have to work on next version, which is out of scope of this course."
This isn't a suggestion, this is a Security Issue.

The ID Verification is passable as it'll need APIs which will verify the ID with the official data, hence we can by-pass that, but not the OTP generation.

[Swi-ft]

And please do not question us about our app, there is another separate dedicated team for that.

[harshitptl21]

You started this issue with the quote
"We have already implemented OTP verification on our own website."

"Gmail detects it as a spam but it is not in case for workplace specific domain, it has a limit of email sending as it was free."
As you mentioned, it has limited email sending — what about after that? A user has to wait? And we don't know what email domain a user is going to use.

This is a testing phase, not a feature suggestion round — please don’t request features just because you think they’re necessary. This feature was never mentioned in any documentation, so it was not implemented.

[Swi-ft]

-> " please don’t request features just because you think they’re necessary. This feature was never mentioned in any
documentation, so it was not implemented."
This isn't a suggestion, this is a Security Issue. (I'm saying this exact thing for not the 1st time)

-> " And we don't know what email domain a user is going to use."
It goes to all domains, thank you.

-> "it has limited email sending — what about after that? A user has to wait?"
And please do not question us about our app, there is another separate dedicated team for that. (Again, please read the comments we give, unfortunately this isn't the 1st time we are saying this)