Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I've registered a GitHub account to test their email verification process. So:
They've sent me an email with a link, containing my username and 40-chars code, like:
https://github.com/users/USERNAME/emails/120066679/confirm_verification/47889d71648523e5d99db5b969f59809c2715fb6
I have not followed the link
4 days later, the've sent me another (a reminder), that I have to verify my email, containing link with another different 40-chars code
So, what was the purpose of changing 40-chars code? As I remember, other services, used to expire verification code anyway. If there is already a username in verification link, is there really a need to do that? In case of brute force, I can just count failed attempts related to specific user and block it, right?
P.S. Also interesting, what is the purpose of emails/120066679 in link? (which is similar for both letters)
There are several reasons why quick expiration of verification codes is the best practice.
If protection with a verification code is deemed appropriate, it's safest to make it not only complex enough but also valid for minimum amount of time. If you only make the code work for the time needed (usually really short), you diminish the risk of someone abusing it. (For example, someone could programmatically 'guess' the codes - the more time for this exercise, the higher chance for success.)
Also, it's not efficient to store data of this kind. It's used once, it doesn't contain any actual information and as soon as it's used, it's ready to be "thrown away". It's not a good practice to store anything that doesn't add value when stored.
In addition, it's fairly rare that users don't use the codes immediately/soon. For the small percentage of cases where the code expires by the time the user tries to use it, it's more efficient to generate new ones.
Well, the purpose of an email validation link is to make sure that you actually own the email. Most validation links simply contain some secret that they send out your way, only in the possession of which may you verify the email address.
The reason they changed the code is because it probably expires. In that case you could not activate the account, so they sent you another in case you'd like to continue.
What if they don't send out a secret like this then?
In that case there is nothing that prevents an attacker from "verifying" emails that they actually have no control over. They could just visit the url with the username plugged in and activate the account.
Normal users would not do this, but spammers might.
For the case of brute force:
If the secret is sufficiently random, and the keyspace is large enough, trying to guess it is a fool's errand.
We can assume this is a random 40 hex char number, which gives us:
16**40 == 1461501637330902918203684832716283019655932542976
possible values for it. It is safe to say that no one will guess this number in the near future.
Related
We have a lot of doubts concerning the changes in the Messenger Platform’s policies.
There is HUMAN_AGENT tag (for which we have already asked permission) which seems to be the one that adapts the most to our processes, but 7 days is still insufficient for us. Could we answer with this “message_tag” 20 days after a user message? What can we do in this case? We have to find a way not to leave the user without an answer.
We plan on using one of the above-mentioned CONFIRMED_EVENT_UPDATE to answer all user messages outside of the 24 hour window. Are there any penalties for us doing so? If there are, what are the penalties? Are they applied at the company level or the page level? None of the messages sent by our company contain what you want to avoid (spams, special offers, discounts, etc.) so we don’t think we should recieve any penalty even when using “message_tags”.
We have thought about using the normal answer and, if the “This message is sent outside of the allowed window” error message appears, we will answer using “message_tags”. Is there any problem for using the first call on a recurrent basis giving errors or should we avoid it? Avoiding it might cause to send unnecesary “message_tags”. Could we answer all private messages using HUMAN_AGENT when it is approved (our answers are always given by a customer service agent)?
Best regards
You do not mention your actual use case, so nobody can suggest any message tags that would match that use case.
Without knowing that use case the answer to your questions can only be:
1) There is no way to extend the 7 days window for human agent tag. If you get approved for it you have a 7 days windows, not 8 and not 20. However most user actions reset that window you should follow up within that window and and make sure the user engages with your bot so the window is reset and you have another 7 days for another update.
2) Abusing tags will most likely result in your page being restricted, make sure to only use them for the allowed use cases as listed in the docs: https://developers.facebook.com/docs/messenger-platform/send-messages/message-tags/
Over the past few months random email addresses, some of which are on known spam lists, have been added at the rate of 2 or 3 a day to my website.
I know they aren't real humans - for a start the website is in a very narrow geographical area, and many of these emails are clearly from a different country, others are info# addresses that appear to have been harvested from a website, rather than something a human would use to sign up to a site.
What I can't work out is, what are reasons for somebody doing this? I can't see any benefit to an external party beyond being vaguely destructive. (I don't want to link to the site here, it's just a textbox where you enter email and press join).
These emails are never verified - my question isn't about how to prevent this, but what are some valid reasons why somebody might do this. I think it's important to understand why malicious users do what they do.
This is probably a list bombing attack, which is definitely not valid. The only valid use I can think of is for security research, and that's a corner case.
List bomb
I suspect this is part of a list bombing attack, which is when somebody uses a tool or service to maliciously sign up a victim for as much junk email as possible. I work in anti-spam and have seen victims' perspectives on this: it's nearly all opt-in verifications, meaning the damage is only one per service. It sounds like you're in the Confirmed Opt-In (COI) camp, so congratulations, it could be worse.
We don't have good solutions for list bombing. There are too many problems to entertain a global database of hashed emails that have recently opted into lists (so list maintainers could look up an address, conclude it's being bombed, and refuse to invite). A global database of hashed emails opting out of bulk mail (like the US Do Not Call list or the now-defunct Blue Frog's Do Not Intrude registry but without the controversial DDoS-the-spammers portion) could theoretically work in this capacity, though there'd still be a lot of hurdles to clear.
At the moment, the best thing you can do is to rate-limit (which this attacker is savvy enough to avoid) and use captchas. You can measure your success based on the click rate of the links in your COI emails; if it's still low, you still have a problem.
In your particular case, asking the user to identify a region via drop-down, with no default, may give you an easy way to reject subscriptions or trigger more complex captchas.
If you're interested in a more research-driven approach, you could try to fingerprint the subscription requests and see if you can identify the tool (if it's client-run, and I believe most are) or the service (if it's cloud-run, in which case you can hopefully just blacklist a few CIDR ranges instead). Pay attention to requesters' HTTP headers, especially the referer. Browser fingerprinting it its own arms race; take a gander at the EFF's Panopticlick or Brian Kreb's piece on AntiDetect.
Security research
The only valid case I can consider, whose validity is debatable, is that of security research (which is my field). When I'm given a possible phishing link, I'm going to anonymize it. This means I'll enter fake data rather than reveal my source. I'd never intentionally go after a subscription mechanism (at least with an email I don't control), but I suppose automation could accidentally stumble into such a thing.
You can avoid that by requiring POST requests to subscribe. No (well-designed) subscription mechanism should accept GET requests or action links without parameters (though there are plenty that do). No (well-designed) web crawler, for search or archiving or security, should generate POST requests, at least without several controls to ensure it's acceptable (such as already concluding that it's a bad actor's site). I'm going to be generous and not call out any security vendors that I know do this.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
I have been trying to integrate Sage Pay using their form integration but cannot get passed the infamous 5080 error. I have been through 10 days of back and forth with Sage support and thay have conceded that they can no longer help and are convinced it is an encryption issue. I have also trawled through the answers here and I cannot seem to get the solution. I have done many integrations using other systems before but the lack of feedback from the system is very frustrating makes debugging almost impossible
Things I can confirm:
- PHP Version 7.0.15, as part of Wordpress install
- passing unique VendorTxCode
- passing all required fields with live success & failure URLS
- passing VPSProtocal, TxType, VendorName and Crypt (confirmed by viewing network tool in Chrome aftre request fails)
- tried both test and live portal using the relevant keys and correct gateways
- had numerous showposts viewed by support and verified as correct format
- confirmed the encryption - supplied an unencrypted string to support, their escalation team encrypted the string and sent back encrypted string - used a string compare app to compare strings and they are identical
- I cannot seem to see Invalid transactions in portal as I dont have a transations tab to view and support said thay cannot even see the request attempst hitting the server.
They keep telling me its an encryption issue Any suggestions as how to best debug this or any unapparent solutions that helped others woudl be of great help - im not sure what is best to post here for you to see but I can as required
Many thanks
Log into My Sage Pay with your admin credentials, create a user and give that user permission to see transactions (etc - just click the lot!). Log in as that user and you will be able to see transactions. Look under Invalid, and you should see the reason.
Check you are using the correct encryption password. They are different for live / test
Failing that, post your unencrypted crypt string here - I will look at it and tell you where you are going wrong.
https://test.sagepay.com/gateway/service/vspform-register.vsp?VPSProtocol=3.00&TxType=PAYMENT&Vendor=sagepaylabs2&Crypt=#ba357b87773ffd296f15443bf65b10324d654c2177ee642055d1d112638ff4a22f1cf3656637dafcc437783ed2f091ddea0b6c6d703b2dfefc7196f85baaf6b6fdea618046b03d8b3ee3fa1594b31957e462d5fe58586ae997425f2f449f3cec21c1d82f9c025d2be1335159a552f000480909f0dba755260a5512a5d20e4b5e98b4e165c0dcaf2ecf7ec503a651ea7d8bb6cb35e9ac1f962f5876306060d188973d93a378750d72046ac2a3b34ef43d43cde9446c157b41ca9299f15ac6498996c4b5f471dd7e69df58c58a46fc567819462aaba78e51f712216bf7e1d5ae2712151144968e842c69ad3807eff0f44b1425ce5f06aa503d2469282720f5b39ec7612b3bf178341737adc8c0401247ecf12b3b5f37a5e9da23ec3a1b2db324cb4c1f4287c2c67ea1f7277b08355693f29162381b2dba77045291434f161d04d5bb07c70025eaa3f682d3701a81e8eb7d06b2485dc70df576adef9791fabb599a66f8c1fbfb84c820ff726eb64a1c721f09aa764e1cca12d05ce7ff8c9f89154c27b4aa57112a30062cbfd69bd2ae6dad591d006fce915aabd2ad9432ff75184de30a44fc50c52ced889982eeedaa1c52dcd2e86114fb8b1b914eb32cfd2e2d06f49a74f6e734cca20008d1b8f328281a
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
In Meteor, what is the most efficient way to check the database to see if something exists while the user is typing?
For example, I'm trying to check if the username exists in database while the user is typing his/her desired name to register an account.
I could create a keydown event to check every time when there's a key stroke, or I could use setInterval, but I feel like that's an overkill.
Is there a built in method in Meteor to do something like this?
I did't see anything like that, so you'll have to built it yourself.
Security
Showing which usernames are taken while typing makes it very easy to retrieve a list of existing users. This could be okay if the user list is available to public anyway (for example in a forum), but in most applications you should avoid that.
Waiting until user stops typing
Users probably type faster than the service is able to check the database. Therefore checking on every key stroke would cause a lot of unnecessary service calls. You should at least implement a delay or wait until the field looses focus.
Forseeing next character
You should try to minimize service calls. For example if someone types "Mic", besides checking the exact name, you could add that "Mick" and "Mic1" are already taken too. Further optimization would be to predict more than one character based on common names, but that probably will never be needed.
Reusing Autocomplete Code
You could reuse some code of a autocomplete component, for example when to trigger a service call. But most of the code you can't reuse, because the user interface is very different.
You might find this smart package useful.
https://github.com/mizzao/meteor-autocomplete
I've always assumed that it's risky to identify users in urls within emails. For example, let's say my app is something like eventBrite. I'm inviting a set of users to an upcoming event. I create unique urls for each user's email which allows them to simply click those url's in the email to accept or decline. Ie, they will not have to authenticate with the website.
If they view the email on a mobile device or a public computer through webmail, then clicking the links will fully accept/decline.
Is this approach too risky? I had assumed you should avoid this as something could see those urls and make requests on them which would trigger false accepts/declines.
It'a an opinion but I would assume the link itself can be more secure than the email actually. You can make the accept link valid only through certain period of time (it would not make much sense otherwise anyways).
Moreover, you can make it pretty much arbitrary long. So it's basically arbitrarily hard to guess.
That would leave two options to "see" the link, that I can think of. Physically seeing it by eaves dropping. But you could generate a mail in the html form, which would allow you to hide the full link behind a hyper-ref text. Like Accept / Decline.
There are several parts to this answer:
Is it secure? Absolutely not. It's security through obscurity. You're betting somebody can't guess the link which, as long as it's a finite string then they totally can and as soon as they do, they can RSVP to your event.
Follow up Does it matter? Probably not. I imagine the chances of somebody trying to spoof an RSVP to an event are pretty slim. I absolutely wouldn't protect anything critical this way but if you're just doing something like event RSVP etc (no money changing hands) I don't see anything wrong with this approach. As luk32 said, you can also make the links valid for limited amounts of time etc.
The real issue here, (unless there's something you're not telling us and this is somehow a high value target) is how likely is somebody to accidentally stumble on one of these links and RSVP to an event they aren't going to? You can make the chances of that exceedingly unlikely by generating the links in a sufficiently random manner so that no two links are a like. In this case, I don't think security is the big concern so much as data integrity. That is, is the data you're receiving valid.