Can my credit card informations be stolen by using a VPN?

[Hip]

Hey guys,

I wonder if my private informations for example credit card informations or Bitcoin pirvate keys can be stolen when I use a VPN.

Can the ISP maybe keylog me?

 

Thanks in advance!!

[Nerdtality]

Absolutely, but unlikely depending on who your VPN provider is. They may use Man in the Middle attacks which are pretty easy to preform. Though, such practices are illegal. You should be fine with the name brand VPNs just try to keep your VPNs in the U.S.

 

If you are describing can someone hack into your VPN tunnel then no depending on what protocols you are using with your VPN.

[Hip]

1 hour ago, Nerdtality said:

If you are describing can someone hack into your VPN tunnel then no depending on what protocols you are using with your VPN.

So and which protocols can't be hacked? Can I choose between protocols when starting a VPN? I'd choose NordVPN

[AngryBeaver]

1 hour ago, Hip said:

Hey guys,

I wonder if my private informations for example credit card informations or Bitcoin pirvate keys can be stolen when I use a VPN.

Can the ISP maybe keylog me?

 

Thanks in advance!!

Can they YES, is it likely NO.

 

Any device that is connected to the web is susceptible to being hacked. Now running a VPN makes sure the path from you to the vpn is secure but after that you are once again vulnerable.

[Nerdtality]

On 4/4/2018 at 2:11 PM, Hip said:

So and which protocols can't be hacked? Can I choose between protocols when starting a VPN? I'd choose NordVPN

Nord is my favorite, I would use their OpenVPN.
They offer other methods of connecting such as L2TP with IPSec, IKEv2 as well. Don't use PPTP though or L2TP alone.

 

The reason why VPN tunnels such as OpenVPN are so diffucult to hack is because they are encrypted and have intrusion protection. Good luck unencrypting a 512bit key file live data.

 

Now the VPN provider could be the bad apple sometimes, but if your using NordVPN your good for green.

[colonel_mortis]

Any website that processes card details is required to use HTTPS when collecting them, so unless there's a company that is violating the requirements your card info is protected against passive attackers, even if that attacker is/has control of your ISP or VPN provider. On some sites (where security is sufficient to meet the guidelines, but not optimal), an active attacker might be able to redirect you to their own site, where you might enter your card details without realising that you're on the wrong site. This can be avoided by checking when entering your card details that there's a lock in the address bar and the domain (the black part in the address bar) matches the site you're expecting to be on.

An active attacker could be anywhere, so there's no protocol that can magically protect you. However, using a VPN means that an active attacker on your local network (such as in a coffee shop) can't do anything, which would protect you against the vast majority of potential attacks.

[Nerdtality]

12 minutes ago, colonel_mortis said:

Any website that processes card details is required to use HTTPS when collecting them, so unless there's a company that is violating the requirements your card info is protected against passive attackers, even if that attacker is/has control of your ISP or VPN provider. On some sites (where security is sufficient to meet the guidelines, but not optimal), an active attacker might be able to redirect you to their own site, where you might enter your card details without realising that you're on the wrong site. This can be avoided by checking when entering your card details that there's a lock in the address bar and the domain (the black part in the address bar) matches the site you're expecting to be on.

An active attacker could be anywhere, so there's no protocol that can magically protect you. However, using a VPN means that an active attacker on your local network (such as in a coffee shop) can't do anything, which would protect you against the vast majority of potential attacks.

Even SSL/TLS encrypted traffic is acceptable to Man in the Middle attacks due to their nature. How ever, Google Chrome (Since version 63) will check the certificate with the certificate authority who was assigned to the domain.

Read more here:
https://en.wikipedia.org/wiki/Man-in-the-middle_attack

[colonel_mortis]

12 minutes ago, Nerdtality said:

Even SSL/TLS encrypted traffic is acceptable to Man in the Middle attacks due to their nature. How ever, Google Chrome (Since version 63) will check the certificate with the certificate authority who was assigned to the domain.

Read more here:
https://en.wikipedia.org/wiki/Man-in-the-middle_attack

That's not quite how it works.

When you go to https://linustechtips.com, the first thing that happens is your browser sends a request to the server asking for a certificate, which both proves that the server is legitimately associated with linustechtips.com and starts the encryption handshake. If that handshake was subject to a MitM attack, the certificate would not be valid for linustechtips.com, and you would receive an error (on this site, it is also configured so that the error also cannot be bypassed using the browser interface), similar to the error received on https://wrong.host.badssl.com/.

This is the case in all browsers.

Chrome 63 may have added additional checks to protect against fraudulently issued or revoked certificates (but fraudulent certificates don't happen, because if one is detected, the certificate authority that issued it is severely punished by browser manufacturers, as is happening with Symantec soon because they issued fraudulent certificates for internal testing), but certificates have always been checked for validity and represent a fairly strong guarantee that you are actually connected to the site that the address bar says you are.

[Nerdtality]

Thats what a man in the middle attack does, it acts like the client and resubmits it to the real client and back the other way again

 

https://news.netcraft.com/archives/2016/03/17/95-of-https-servers-vulnerable-to-trivial-mitm-attacks.html

[colonel_mortis]

9 minutes ago, Nerdtality said:

Thats what a man in the middle attack does, it acts like the client and resubmits it to the real client and back the other way again

TLS explicitly protects against that using certificates, as described in my previous post. If you are using HTTP rather than HTTPS, your connection may be being MitMed and your traffic being read by an attacker before being passed on, but if you are using HTTPS then there is a fairly strong guarantee that your communication with that site is not being MitMed. From the wikipedia article that you posted earlier,

Quote

As an attack that aims at circumventing mutual authentication, or lack thereof, a man-in-the-middle attack can succeed only when the attacker can impersonate each endpoint to their satisfaction as expected from the legitimate ends. Most cryptographic protocols include some form of endpoint authentication specifically to prevent MITM attacks. For example, TLS can authenticate one or both parties using a mutually trusted certificate authority.^[2]

 

 

3 minutes ago, Nerdtality said:

https://news.netcraft.com/archives/2016/03/17/95-of-https-servers-vulnerable-to-trivial-mitm-attacks.html

That is not an attack against HTTPS/TLS itself, it just allows the attacker to inject their MitM before your browser is redirected to HTTPS and therefore prevent you from being redirected.

When you go to http://badssl.com/ (which is one of the few websites that I can find which would be vulnerable to this and it is deliberately like that; note that it is HTTP), you will make an unencrypted request to the server first, which will then perform a redirect to the encrypted version, https://badssl.com/. The attacker can prevent the redirect and keep you on the HTTP version, so they can MitM you. However, sites can tell the browser to never try to connect over HTTP, and instead to force HTTPS always, and that blocks the attack.

When your connection is being subject to a MITM using that technique, the address bar will either show http:// (and no padlock), or the domain will have changed to one controlled by the attacker. This is why I said, and stand behind, the following:

47 minutes ago, colonel_mortis said:

This can be avoided by checking when entering your card details that there's a lock in the address bar and the domain (the black part in the address bar) matches the site you're expecting to be on.

 

[LogicalDrm]

Why, just why, would your ISP keylog random people? Why they would do it for anyone? You are paying big bucks to use service. They could get bigger moneys much more easier ways than banking your card data. They could just slowly add extra costs to your bills. Rather than draining your bank account at once, they could just suck it dry over months and years. Only those who lack infrastructure to gain money in slow, but steady flow do something so drastic like hacking for pure monetary gain.

[Anugo]

Quote

 

Internet is never a secure place, so its possible to hack and get all the information but to make this process safe and secure VPN services are there. Before confirming a VPN service provider please go through their terms and policies. But, yes you will be safe from the hackers and from your ISP. I am using Acevpn service and till now I didn't face any issues like this.

[wasab]

Nothing that NSA can’t crack. Just wait until their secret quantum computer is finished. 

[Jihakuz]

@colonel_mortis I don't have a great idea about how VPN's work, so correct me if I am wrong. I do however have an idea how HTTPs works. It encrypts your data with some form of asymettric encrpytion method. This uses two keys, which are unencrypted? So if a VPN is able to see all the data sent from your PC to the server, they could see the key? That's probably wrong by oh well.

[LAwLz]

Linus really needs to make a PROPER TechQuickie about VPNs... It is astonishing how commonly it gets recommended/used, yet people don't know how it works even on the most basic level.

 

A VPN will only offer some extra protection for your credit card data if you are, for example, on an open wifi in a coffee shop.

 

 

On 4/4/2018 at 10:22 PM, colonel_mortis said:

Chrome 63 may have added additional checks to protect against fraudulently issued or revoked certificates (but fraudulent certificates don't happen, because if one is detected, the certificate authority that issued it is severely punished by browser manufacturers, as is happening with Symantec soon because they issued fraudulent certificates for internal testing), but certificates have always been checked for validity and represent a fairly strong guarantee that you are actually connected to the site that the address bar says you are.

Chrome 63 added a very obvious screen (covers the entire window) for when it detects the use of certificates another applications has injected into Chrome. For example your company might want to decrypt all your HTTPS traffic at their firewall. In that case they might have pushed out and installed a root cert on your company computer. That allows them to MITM your TLS connections.

 

You don't need to worry about your ISP or some coffee shop doing that type of MITM attack on you though, because they need to install a cert on your local machine in order to pull it off.

 

I am not saying this to argue against you, because you are 100% correct in everything you said. I am just pointing out which new feature Chrome 63 added. It is not relevant to this topic though.

 

 

 

 

1 hour ago, Jihakuz said:

@colonel_mortis I don't have a great idea about how VPN's work, so correct me if I am wrong. I do however have an idea how HTTPs works. It encrypts your data with some form of asymettric encrpytion method. This uses two keys, which are unencrypted? So if a VPN is able to see all the data sent from your PC to the server, they could see the key? That's probably wrong by oh well.

You're partially correct.

Asymmetrical encryption is used during the key exchange process. However, the good thing about asymmetrical encryption is that it does not matter if someone sees the keys being transmitted.

 

Asymmetric encryption works by having two sets of keys.

• One key to encrypt information, which is called the public key. This key can only encrypt information, and websites can and will freely announce this key to anyone who asks for it.
• The other key is used to decrypt information, and this one is called the private key. It is called private, because this key should NOT be shared with anyone.

 

This is a simplified version of what happens when you browse a HTTPS website:

You: Hey LinusTechTips! I gimme your public key!

Linustechtips: Sure thing buddy! It's 1337!

You: *Uses the key 1337 to encrypt a message*

You: Here you go LinusTechtips! This is the message I wanted to send you!

You: *Sends the encrypted message*

LinusTechTips: Thanks! I got your message.

LinusTechTips: *Decrypts your message using their private key, which is 1234*

LinusTechTips: *Reads your message*

 

 

The key 1337 can not be used to decrypt your message. It can only be used to encrypt it.

 

If someone like colonel_mortis intercepted this conversation, the only thing he could know would be the public key 1337, and the message you sent. However, 1337 can't decrypt your message. 1234 decrypts it, but only LinusTechTips knows their private key is 1234.

 

 

Here is an analogy that might easier to understand.

I want you to send me a message, but I don't want the postal service to be able to read it.

What I do, is buy a lock with a key (like the one pictured above). I then send the lock to you (in its opened state), but I keep the key for myself.

You put your message in a box and then lock the box with the lock I sent you.

You can close the lock, but since you don't have the key you can't open it, and neither can the postal service. Once you close the box and put the key on, only I, who has the key, can open it.

So you send me back the box, I open the lock with my key and then I can read your message.

 

 

Edit:

Since we are on the subject of encryption, I want to share this video about a really cool public-key protocol called Diffie-Hellman (off topic but some people might be interested). Diffie-Hellman (DM) It is not really encryption, but it is used to set up encryption. The first 2 minutes explains everything on a basic level using colors. The rest of the video is how the actual mathematical function works, using numbers.

 

[Donut417]

On 4/4/2018 at 1:53 PM, Hip said:

Hey guys,

I wonder if my private informations for example credit card informations or Bitcoin pirvate keys can be stolen when I use a VPN.

Can the ISP maybe keylog me?

 

Thanks in advance!!

Target, Equafax, and others, got hacked and your info was put out in the world. Using a VPN wouldnt have helped in any of these cases, Well maybe the Target  one, though Im not sure how the card data was breached. Most of the time these hacks happen due to lazy IT staff or under funded IT departments not doing what needs to be done to protect the data. 

[Razor Blade]

22 hours ago, LAwLz said:

A VPN will only offer some extra protection for your credit card data if you are, for example, on an open wifi in a coffee shop.

This is the main reason I got a VPN. Though it isn't completely foolproof.