That sounds like an interesting idea 
3 Likes
So you never do online shopping/things that need CC? I was able to get a .pp.ua domain using @Repetza 's CC 
I donât know pp.ua as well as I know Walmart and Amazon. Account Security Is Priority.
If you are associating security with TLDs, stop. A pp.ua domain can be way more secure then a .com or .net (The opposite is also true).
Humans tend to associate trust with things that are familiar (Hence the continued popularity of .com and .net), but TLDs are absolutely not a way to establish real trust (there are exceptions, like .dev is HSTS enforced, .gov is usually a secure US government entity, etc).
Perceived trust, and something that is actually trustworthy are very different, the difference between the two is what powers a lot of internet scams. Be careful!
5 Likes
The attacker can create any dummy account as a workaround. By creating fake accounts, the logging system for links is somehow useless in this particular aspect. I know a possible fix. Only users with verified account information should be able to visit the original link from the support URL.
I like the idea of implementing support URLs as an additional preventive layer for accessing any sensitive information, including the original website URL or domain name.
In addition to that, it would be better if a warning message aka disclaimer exist on every link access. In order for a certain user to proceed, he/she need to understand his/her responsibilities for visiting the link, including the confidentiality of the link being shared. To ensure that user understands and agrees with the conditions, a checkbox or some sort of input is required to accept the conditions before proceeding.
But again, the existence of a possible dummy account is still huge problem in this aspectâŚ
Not really, because you can put limits on the number of pinâs a new account can access. Then the multi-account prevention software on the signup page will effectively make it not worth the effort to spend 10 minutes just to get a single URL
3 Likes
Only when the attackerâs account has been recently created. Workarounds still exist for that.
- The attacker can use an existing dummy account before the solution is going to be implemented (from the time this topic has been posted).
- The attacker can create new dummy account and spends time long enough to gain higher trust level adequate for getting access (similar to what has been told by @Admin in previous post).
Not the point I was stating.
I donât know the pp.ua registrar. If I knew them well, I wouldnât mind adding my CC to the account to get a pp.ua domain. But I donât know the registry well.
I know Walmart well, I can trust them because Iâve been to their store many times. Iâve established trust with them.
I know Amazon well because I have been with them in the past. I know their practices, so I trust them.
The pp.ua registry is new to me, and the way they handle providing pp.ua domains requires me to establish a form of trust with them first. I understand that a CC is needed to get a pp.ua domain because of verification, but I donât know how they handle the CC info yet.
Before we go off topic about trust, letâs talk about how iFastNet is now setting my ticket to Pending, refusing to comment on if they are investigating or ignoring.
iFastNet will possibly never listen to our genius solutons. I know @Admin would give feedback on ideas here, and possibly implement them, but I have a feeling iFastNet doesnât listen to ideas at all.
A support PIN mainly makes sense to authenticate users in a support system. When your application and support system are separate, a support PIN lets staff check your support request against the support PIN on the application profile so the support staff knows they are dealing with the account owner.
But because the forum relies on the client area for authentication, itâs already known exactly which client area profile every forum user is linked to.
So I can already lookup peopleâs accounts and domains based on their forum username. The problem with that is that nobody else can find that information. Which means it doesnât work for the âeveryone should be able to helpâ.
Iâve been exposed to a lot of BS with exotic ccTLDs. The whole .PE issue being a very recent example. .com and .net domains are a lot less hassle in my experience.
With pp.ua specifically, you could argue that the ongoing threat against the sovereignty of the Ukranian state also poses a threat to the operation of the .UA domain extension.
As for trust into individual domains, I wouldnât want to give my money to a business who doesnât even spend $10 per year on a domain name. Having a .com domain doesnât make a business trustworthy, but not having one is suspicious.
Dummy accounts are a possible issue, but at least you have an email address and IP address, which is more than what we have now.
And once the initial system is setup, itâs of course possible to further shore up the defense and limit access to some users.
What exactly makes for âverified account informationâ in this system?
Linking the access back to forum TL levels could help. Only making the information accessible to TL1+ users enables broad access while making it hard enough to create dummy accounts.
5 Likes
Sorry, I should have explained a bit more.
I was thinking of allowing users to generate unique support pins for each individual account (So the /supportpin page prompts the user to select an account, then provides the code and instructions).
Forum users can then enter that PIN into a web form in the client area and get the information needed.
4 Likes
Ah, right, that makes more sense. Itâs similar to what I proposed, only with access codes instead of access URLs.
6 Likes
Yes, thatâs what I was going for
That way there is less confusion of âwhy does this not load in my browserâ?
5 Likes
Email addresses can be created with false information. I do not know if the client area possesses an ability to detect temporary email addresses during signups, but we know that these types of email addresses exist and have been used commonly in illegal activities.
For example, in order to bypass the monitoring system, a wise attacker should never create any temporary email address that
- can be detected easily during the sign-up process
- contains information that can be traced by others
He/she might use any legitimate account information from others (aka identity theft) to create the email address he wanted. He might even register the email address on a highly trusted email provider such as Google Mail to bypass the basic temporary email address detection measures. The original owner of the information can be blamed and sued for the damages, violations, and illegal actions done by the attacker. Of course, the original owner of the information can deny the allegations after he/she knows about it, but it becomes too late for him/her to act, especially when the email address has been made accurately to resemble his/her own personality and identity.
Another two problems arise from that problem:
-
How could we trace the attacker through the email address if the email address itself was fake? Even if we report it to the email provider to trace the attacker (assuming we had appropriate authority), if the details used to create the email address were fake and/or stolen from others, then itâs unlikely that the email provider could help us in that matter.
-
How do we know if the email address is fake and stolen aside from looking through the format of the email address and the reputation of the email provider and/or mail server?
While it is not a major responsibility of Infinityfree to validate the credibility of the email address (itâs a burden that needs to be handled by email providers), it is still part of a problem that Infinityfree is trying to solve. If we want to rely on email addresses for tracing these attackers, we have to consider the factors and implications.
IP addresses can be falsified too, using virtual private networks and proxies. Not to mention Tor already exists. Unless the forum does not allow users who use VPN or proxy, the IP address cannot be relied on.
We know that itâs impossible to detect all the VPNs. If the forum cannot detect all the VPNs, then it is impossible to tell which users have used VPN services. Because of that, itâs difficult to block all the forum access which uses VPN services. How much more if the attacker uses Tor with obfuscated bridges and other measures to avoid getting detectedâŚ
However, the only thing we can do is to trace which server has been used by the VPN and use the information about the VPN servers to guess which VPN provider has been used to access the forum. If we can trace the name of the VPN provider, then probably someone with authority can create a request to the VPN provider to help us gather information about the attacker (which requires legal process, maybe). Itâs possible but itâs very time-consuming to do. Not to mention the level of uncertainty it possesses.
The attacker can use multiple layers of secure VPN connections to avoid getting traced, even though itâs impractical to do so. It has many disadvantages, though. As far as I know, it can result in more network delays than usual. Depending on the attackerâs Internet connection, the act of scrapping the links may take a while before itâs finally done, unless he/she is very persistent about it (maybe due to vengeance or something like that, we really donât know the intention yet).
It would be hard to track future attackers if we only relied on these information. It can be falsified and manipulated. We need something concrete that can be used to figure out the potential attackers from the list of users who had tried to access a certain link in the forum. I wonder what could it beâŚ
2 Likes
I think we had overlooked something important. No matter how strong we may build a system that protects the links from being leaked, the fate depends upon the users of Infinityfree. If a certain user exposes the link to the website outside the forum and gets attributed and/or linked with Infinityfree somehow, then itâs a game over for him/her. Those attackers might collect the information an attack requires outside Infinityfreeâs control.
Letâs assume that we had implemented proper security measures to protect the links.
Does it mean the hacker can no longer gather the links in which Infinityfree has connection with? Not really, but at least the possibility of getting leaked is lower than usual.
I have some doubt with the effectivity of the security measures. What will happen if the attacker can figure out the websites associated by Infinityfree just by looking at the usernames and other information from the user profiles in this forum?
Some of the websites in Infinityfree resemble forum usernames, or at least include partial fragments or hints about the owner. If the website has already been indexed by any search engine, the attacker can perform a search using the information which has been collected from the forum to find out the exact URL of the website, regardless of the search engine being used to search for.
3 Likes
My current plan is to make the support links only accessible to users who have at least Trust Level 1 on the forum. In my opinion, it strikes a good balance between allowing legitimate forum members to see it without making it accessible to everyone.
Yes, itâs not fool proof. Yes, itâs possible for people to sign up with specially created email addresses and use a VPN. Iâm quite proud of how good the system to block disposable email addresses works, but it doesnât stop people from just created another free email address with a widely used provider.
Requiring a forum trust level makes it harder to create disposable accounts to see the info. Not impossible, but more difficult to do anonymously.
I know that none of these things are perfect. But thatâs not a realistic standard. The only way to be sure is to basically never make any details accessible to anyone. But that effectively means that we canât have a community support forum anymore, and thatâs not a step Iâm willing to take.
And yes, there are still plenty of ways to find peopleâs website without the links being shared in the forum. Like guessing them based on usernames or searching the web. There is nothing we can do about that. If people are looking for a way to hurt random InfinityFree users, there are still plenty of ways to do that.
7 Likes
Sounds like youâve really thought this through
Once itâs in place, If youâd like a hand testing anything. iâm always up for helping out
5 Likes
I am also up for helping out too!
4 Likes
I want to help, too!
5 Likes
I donât need any testing at this time, but Iâm not sure what would be a good idea for the information that is shared through the support links.
A few ideas that crossed my mind:
- Just have a free form text box for people to put whatever they want. With the danger that people donât provide the information thatâs useful for support.
- Being able to select from the domains that are linked to your account. But thatâs difficult if there are domains that are not yet added. And how to deal with exact page URLs?
- Also be able to select to show account usernames, although the reasons that sharing website URLs might be a bad idea donât apply to usernames.
- Same with database names.
I hope itâs possible to create a system that enables people to share more specific information that is relevant, but also encourages people who might be more sparing with details to provide the required information.
5 Likes