What are the SQL-injections issues of parameterized queries?

You are already using parametrized queries which protects you against injection of SQL parts, assuming you are always using parameters for untrusted data.

As you said that leaves the issue of wildcard characters in operators that support them. That is, if you are using "=" instead of LIKE, the problem will not arise. In most cases, in which LIKE is used intentionally, a search with user supplied data is desired. So adding more wildcards is likely not an issue.

Adding a wildcard at the front, however, may have a significant performance impact because prefix indices cannot be used efficiently. So if your dataset is huge, you may want to filter them. The standard wildcars are % and _, but some databases support additional characters such as *.


Why does facebook php sdk (and multiple others clients) include CA bundle with a lot of CAs?

Like written in the File Head, this file is basicly just a copy of the CAs from Mozilla. This allows the use in cURL, to check if the Certicate is valid or not.

It is not like this would be tons of additional random CAs, it is just a copy of something the most browser will already have, just attached to use it with cURL or anything else.

An issue could be if one CA gets compromised, you had to remove it manually from the file, since it is not bound to any updater like a browser.


Network with one possible unsecure device and one home assistant device

There may be a lot of vulnerabilities in your setup:

As you plan to connect your devices with wifi, you open up at least for signal jamming. There are a lot of possibilities for  a thief, like simply deauthenticate your cameras while he passes them (I expect the cameras not having an internal memory). Dependent on the wifi encryption it could also be (relative easily) possible to eavesdrop the communication between the devices.

You said you do not have other devices on the network. So you are  planning to have a isolated wifi network? Or is this your regular home network? Dependent on that, there are a lot of additional vulnerabilities for your system. Every other device could be used as a target.

If you have an isolated wifi network, an adversary could also try to penetrate it. If you are not monitoring, you wouldn't even recognize that there's an intruder. When the intruder is in your network, it should be easy for him to manipulate data, inject new data or simply eavesdrop. He can target each layer of the protocol stack now, especially if your "cheap" cameras use bad crypto.


How to obtain Service Tickets (TGS) for Service Accounts with no SPNs (ServicePrincipalName) set?

A service ticket is a very specific thing. Active Directory will only let you request service tickets to principals that have SPNs registered because otherwise it's not a service principal as far as Kerberos is concerned. This is for correctness and security reasons.

If services really need to use Kerberos to authenticate to a principal that doesn't have an SPN available to it, it will attempt User-to-User authentication which relies on shuffling the encrypted TGT between users and the KDC, and encrypting the service ticket to the service TGT's session key.


What prevents me from launching an SYN-ACK flood using HTTP servers?

This is a long known-about attack called a "reflected DoS". The reason it mostly doesn't cause much of a problem for defenders is that receiving an unexpected SYN+ACK doesn't take up any state on the target server; at most it may send back a packet to say "uh, sorry, wasn't expecting that" which may cause some saturation of their network connection in a scenario where the attacker has a lot of bandwidth at their disposal, but mostly this isn't very useful to attackers. Most of the time, the firewall in front of the service will see that there's no open connection and just drop the packet silently. In general, SYN and SYN+ACK packets are very small, so you need a huge number of them to cause any problems for a defender in terms of flooding.

By contrast, the reason SYN flooding is sometimes effective is not that the network link becomes saturated, but that the server's TCP stack is expecting the new clients to send an ACK and must maintain state until that wait period times out, causing the half-open connection limit to be reached and new connections from legitimate users to be denied. This is, however, mostly mitigated in most sensible scenarios by use of modern TCP/IP stack implementations and defensive measures such as TCP cookies and firewall / IPS rules.

The type of flooding reflection attacks more commonly seen are those which amplify the attack in the process, whereby small packets sent by an attacker generate large response packets from the server, allowing the attacker to amplify the volume of traffic significantly. This was mostly initially exploited against DNS servers, but more recently attackers have identified many other services which produce even greater amplification coefficients, particularly NTP.


As you may be aware, that line in /etc/sudoers allows user2 to run any arbitrary rsync command as root. This could be used to read or write any system file, including your password hashes and modifying the sudoers configuration to grant more access. rsync alone could even be used to run commands as root.
So it becomes clear that user2 can easily become root and do anything to the system. Your attack surface increases greatly when considering that user2's account is accessed remotely from other systems. If another system is compromised, an attacker could easily pivot to your backup server and become root. Not great on a backup server, that's for sure.
Probably the best thing you could do in the current scenario is to limit the sudo command further. If you are running the same rsync every time, you could probably hardcode the entire server-side rsync command, arguments and all, in the sudoers file. This way, sudo is only useful for doing the backups. You may need to do a little investigating to see exactly which command is being run on the server side.
Or, if user2 is only used for backups, you could make a custom rsync validation script for allowed commands and force it to be called using command= in user2's ~/.ssh/authorized_keys file, but filtering like this is difficult to make airtight sometimes.
Alternatively, the TAR format can be used to preserve attributes, and there are a number of solutions out there to do networked TAR backups.


If I have a valid certificate for xxxxx.target.com, can't I read *.target.com's cookies?

Here, I am able to upload files under my sub-subdomain that is I can upload files as myname.xxxx.target.com/myownfilename.extn. Is this vulnerable?

As long as an upload to your sub-subdomain does not get mapped to a URL in the main domain which can be used for domain validation I don't see any problem here. And if this is the case depends on the specific server setup which is unknown.

  ... is /.well-known/acme-challenge/ this path a standard for http file upload verification

This is the standard path defined in the ACME protocol which is used by Let's Encrypt and some others.

  ... Is there any other ways to get the domain verification done in this case to get valid TLS cert?

The scenario you describe is not that uncommon. It would be very bad if this could be used to get a valid TLS certificate. Given how common it is I don't think that you can get a valid certificate this way.

  In short, if a server, say target.com have auth cookies set to *.target.com and also allow users to upload files under target's subdomain but not exactly to /.well-known/acme-challenge/, is this situation vulnerable?

The scope of the auth cookies has nothing inherently to do where a file uploaded to some subdomain will occur in the main domain (if at all). Based on only these information there is no vulnerability.


Good resources on ACH/banking details security?

PCI doesn't have anything to do with banking information, and may not be applicable depending on your hosting situation. PA-DSS deals with web applications.

I would very seriously consider the risks involved in this, compared to the monetary benefit you derive as a result of accepting and storing this information. A data breach of this information may expose you to a great deal of risk and expense. For example over 30 states have their own beach notification laws, and timelines for how long you have to contact the state attorney general, customers, etc. You may have only a day or two in many cases and the legal fees alone would be very expensive.

Beyond that, you are often responsible to notify all affected customers in most of these states by mail. Many companies end up purchasing/providing free credit monitoring and you may be sued by banks or individuals whose accounts are compromised in order to cover actual losses, including actual funds and bank resources. You may face additional, personal liability if you don't follow industry best practice, which typically would include code and pen test review of all releases and updates, annual audits, encryption, file integrity monitoring, web application firewall usage, SIEM, IDS/IPS, and the list goes on.

This is not all to scare you, but to convey the seriousness of the undertaking. If you are determined to store banking-related PII I would strongly consider consulting a lawyer or an experienced banking industry IT security professional. At the very least, I would talk to a few of the larger banks in your area and ask what they would require if you were operating a service like this for one of their business clients.

Disclaimer: I'm not a lawyer, views and thoughts are mine and mine only, etc, etc.


Why JSON Hijacking attack doesn't work in modern browsers? How was it fixed?

The JSON issue that led google to prepend while was a same-origin breakdown in early versions of firefox (1.5 and 2b specifically) where the JSON file could be loaded as a normal script tag from off-site, and have its data reachable.

Normally JSON files don't "tell" the JS engine to do anything if loaded as a script, so they have/leave no reference to their data structures. JS's security is reference-based, so that assumption is fine. JSON Object literals ({})are actually an ambiguity to JS's engine since they look like code braces, causing those to syntax error. The problem with old FF was that one could use obscure runtime modifications that caused Array literals to execute some other code when parsed/created. That other code could introspectively reach the array's contents, which was a bug.

There were related issues with XML, as firefox considered some XML shapes to be valid JavaScript(tm) using FF's E4X extension (Ecmascript4XML). IE had some issues with non-js content being loaded as a script, erroring out, but revealing the contents to a pre-applied global error handler, which reported the source of the "code" causing the issue.

Since there are now viable safe ways of grabbing remote JSON content, the vulnerabilities of obsolete browsers and JSONp/eval() exploits no longer apply to loading content. If you try to load a valid JSON resource as a script, you cannot reach the contents from other JS.

Lastly, I don't think this actually has very much to do with security; php, curl, python etc don't give a hoot about the browser's rules; if data is out there it's out there. The only thing the same-origin policy does in that regard is prevent run of the mill "deep-linking" resource stealing of non-secret data.


Does using Bcrypt to encrypt credit card numbers satisfy PCI compliance?

I understand that using MD5 is not safe and is not PCI compliant.

Sadly enough, it rather can be in some cases: https://security.stackexchange.com/a/41868/836

Does using BCrypt satisfy PCI compliance

The substantive problem is that the credit card number space is so short that brute forcing is basically always reasonable. I think that the question pattern you should be asking is:

"Am I allowed to store this data?"
"What is the most secure solution to what I'm trying to do?"
"Is the solution I came up with compliant?"

Thus, what we should be talking about is why you need to store this data and how you'll access it, confirming that PCI says you can store it, then figuring out the appropriate response.
... here's the direct answer:

3.4 Render PAN unreadable anywhere it is stored (including on portable digital media, backup media, and in logs) by using any of the following approaches:

One-way hashes based on strong cryptography (hash must be of the entire PAN)

... which BCrypt would satisfy. Further reading: https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf


This sounds like you might be looking for some of what is covered in the CERT-RMM.

http://www.cert.org/resilience/products-services/cert-rmm/index.cfm

I suspect the scope of the Resilience Management Model may exceed your current project but the objective you describe appears to be part way down the path of what RMM codifies.  One other tangental benefit is that you can point to the work that you are doing as following a documented and promulgated system.


Which conferences are comparable to the Defcon?

There are many, I searched for some of them in different forums:

HITB Security Conference
Black Hat (various events and conferences every year every where)
B-Sides (much smaller but more populist conference)
The Hacker Conference (first organized in 1984)
Blue Hat (Microsoft Hacker Conference hold twice per year)
Brucon (conferences, training ... once a year, Belgium)
TROOPERS (once per year, Germany)
Growth Hacking Conference (UK)
Virus Bulletin (once per year, coming one by the end of September)
Hack.lu (annual,  coming one on 20-22 October 2015, Luxembourg )
NDSS (annual, last one done on February 2015)
nullcon (once a year, last conference done on  06 - 07th Feb 2015, in Delhi and Goa, Asia)
RSA Security Conference (annually in USA)
SecureWorld Expo (annually, USA)
Hacker Halted (annually, placement changes every year)
DeepSec (annually, their conferences are always published on Youtube, Austria)
Hackito Ergo Sum (April of each year, Paris-France)
ICM (more about cryptography)
SIN ACM (annually, next conference on September 8-10, 2015, Russia)
CanSecWest (on March of each year, Canada)
ASIA (annual,  cyber security conference, USA)
FSec (annual, coming conference on 14th—16th September 2015, Croatia)


Are you sure you need link-layer encryption?  For most purposes, application-layer encryption is sufficient.

If you really need link-layer encryption, your best bet is probably going to be to tunnel your traffic over some secure tunnel (OpenVPN, SSH, IPSec, etc.).  While it is possible to design an IPSec-like protection into your protocol, that is a non-trivial task that requires competent cryptographers and will require looking at the detailed specifics of your protocol.  It's not something we can do on this site.

If you don't really need link-layer encryption, I think it's going to be a lot easier to deploy application-layer encryption.  Basically, you encrypt the traffic that is sent over your protocol.  If your protocol guarantees reliable in-order delivery, use TLS.  If does not, I suggest using DTLS.  These protocols have been carefully vetted, many implementations are available, and  it should be pretty straightforward to layer them on top of your protocol without fear that you will introduce some crazy subtle security bug in the crypto.


It looks like the network adapter that is connecting to your network using the MAC address that you show is likely made by LCFC(HeFei) Electronics, as some of the network adapters that they produce have MAC addresses in the E8:6A:64:xx:xx:xx range.  See https://udger.com/resources/mac-address-vendor-detail?name=lcfchefei_electronics_technology_co-ltd.

If you don't recognize this device, see Unknown MAC address connected to router for some ideas as to how to proceed next.


What is the status of Certificate Transparency?

As of today (January 25, 2018), adoption of Certificate Transparency is not ubiquitous, but it is starting to gain momentum. Let's Encrypt logs all their certificates to CT logs, and several major CAs like DigiCert and Comodo run their own CT logs. Google Chrome already displays Certificate Tranparency information in its Dev Tools, and Firefox plans to add support in the near future.

Starting in April 2018, Google Chrome plans to start enforcing the use of Certificate Transparency in all newly issued certificates by refusing to treat them as valid unless they're included in at least two distinct, qualified Certificate Transparency logs. Once that happens, Certificate Transparency adoption will undoubtedly take off rapidly, as very few site operators will be willing to use a certificate that is not trusted by Chrome.


Why is using an SSH key more secure than using passwords?

Both keys and passwords have their pros and cons.  The reason that "howtos" and the like advise using the SSH key is that they find their cons less worrisome than passwords' cons.

SSH keys are long and complex, far more than any password could be.  But as you state, they don't have expiry, and they sit on disk where they can be stolen from.  On the other hand, they don't get transmitted to the remote system (except key forwarding, natch) which passwords need to be.

Passwords are generally, predictably, unavoidably weak.  While it is possible to have strong passwords, time and again it has been shown that people will use weak passwords and have poor password practices... short, simple, word-based, simple patterns ("p@ssw0rd!"), write them down, use them on multiple sites, base them on their phone number, their children's birthdate, their own name.  You point out that keys don't expire, but why do passwords expire?  To ensure that a brute-force attack is less likely to crack a password before it's been replaced.  Not an issue that impacts keys.

And, bad passwords aside, even "good" passwords are vulnerable to brute-force (online or offline) under the right conditions.  They have to get transmitted to the other system, or to any other place that the user can be fooled into sending them by mistake.

The balance of evidence strongly suggests that passwords are weaker and keys are stronger.


Digital preservation: cryptography for long-term archiving

It is safe to store encrypted data for 5-10 years, but not all drives last that long.

  I worry that, if I store and forget the data, it would not be possible to open the container any more at some point in time (5-10 years).

There is no reason why the encryption itself would fail to work after 5 or 10 years. As long as you remember the password and the drive is still working, you will be able to decrypt it. The algorithms that are used have a very long life. Even old algorithms like DES from more than 10 years ago are very easy to use. Simply put, encryption algorithms do not care at all about the current date.

Think about it this way: A 10 year old hard drive with a SAS interface (2004) encrypted with AES (2001) and formatted with the NTFS v3.1 filesystem (2001) would not only be trivial to access on modern hardware, it would not even be out of place to see today! Even a 20 year old hard drive with a PATA interface (1986) encrypted with 3DES (1998) and formatted with the FAT32 filesystem (1996) could be easily accessed today, in 2018. And you're worried about only 5 to 10 years?

However, I need to point out that 10 years is a long time for a hard drive. Even if you are keeping redundant backups (e.g. by using RAID 1), you are risking the hard drive itself dying from old age. Encryption will not prevent the drive it is stored on from dying. If you do need long-term archival, there are plenty of resources online to learn how to properly store data for decades.

  Another issue is whether the whole container could be damaged by a couple of flipped bits here and there.

That depends on which bits are flipped. All block ciphers (such as AES) require a mode of operation to work properly. Modern LUKS setups typically use a mode called XTS. Being a narrow block mode, a single bitflip will always corrupt 16 bytes (128 bits) of data. This may be enough to cause corruption in the underlying filesystem, but a corrupt filesystem can almost always be fixed, usually using automated repair tools. It is important to realize, though, that it is more likely for an entire sector (usually 512 or 4096 bytes on modern hard disk drives) to fail. It is fairly uncommon for only a single bit to be flipped, but not uncommon for a sector to "go bad" all at once. The hard drive will make a best effort to recover the sector's contents and copy them to a fresh sector, but it can only do so much. If it is unable to recover the sector, it is marked as damaged and is lost.

LUKS also contains a feature called "anti-forensic key splitting" (see page 10 of this document). This is a cluster of data spanning typically 250 KiB and contained in the 2 MiB header. If a single bit is corrupted in that region, the entire volume can be lost*. Its purpose is to make it easier to erase data quickly in the case that erased data can be only partially recovered, but it also increases the risk of accidental data loss. Unfortunately, this feature cannot be disabled in the current version of LUKS. Unless the header itself is damaged, the rest of the volume should remain intact.

Because this feature cannot be changed when using LUKS, it may be better to use different disk encryption software. VeraCrypt takes the opposite approach of LUKS, not only making its header as compact as possible, but keeping a copy of the header just in case the primary header is damaged. Linux fully supports VeraCrypt when a modern copy of cryptsetup is used. It does not require any extra software and even uses dm-crypt as a backend, just like LUKS.

  How do things like LUKS actually last?

I would only start worrying when the data approaches half a century of age. At that point, you run a high risk of not having access to any hardware which is capable of interfacing with your storage device or executing the LUKS software. After that much time, it's possible that even the LUKS specification will be lost, making it necessary to reverse engineer the format. If you are only storing data for 5 to 10 years, you do not have to worry about that kind of thing at all. I have storage drives with data that old and have never had any problem. The only thing you need to worry about is your storage medium failing due to age, which you can deal with by keeping redundant backups.

Overall, there are three things you need to keep in mind when archiving data that long:

Algorithm support. Encryption algorithms that are well known will continue to be supported for a very, very long time. There is no reason to worry about an algorithm like AES becoming ancient history after a mere 5 to 10 years. In fact, it will likely still be the most popular!
Storage medium compatibility. Over time, interfaces for storage devices become obsolete and the hardware required to interface with them becomes harder to find. This starts to become an issue as the age of the medium begins to be measured in decades. Even with this issue, for a popular interface (like SATA), chances are you will find plenty of retrocomputing fans who will know how to access data on even the oldest of devices.
Storage medium health. One thing you cannot prevent is the progression of time slowly damaging hardware. While some types of media last longer than others, everything will break down. I would be very uncomfortable keeping extremely important data on a hard disk drive or a solid state drive, but I would not feel too worried keeping it on an archival DVD. It's important to periodically test your backups to make sure the hardware still works.

To reduce the risk of loss of data loss when archiving, you should follow the 3-2-1 rule. This rule states that you should have at least three separate copies of your data, of which two should be kept on different types of media, and one copy should be kept at a remote location. The specific kind of media you will want to use depends on multiple factors. In general, you should know that:

High-capacity tape drives last for a long time, but require expensive hardware.
Archival DVDs† last a long time, but have a low storage capacity.
Archival hard drives don't last as long as some solutions, but have a high capacity.
Solid state drives begin to lose data in the span of years to decades.

* While a single corrupt bit in the header can corrupt the entire volume, it is still possible to recover it by using a brute force attack. If more than a single bit is corrupted, the chances of recovery become significantly lower. If an entire 512 byte sector is lost, which is the normal failure mode of modern hard drives, there will be absolutely no way to recover the encrypted data if that sector was part of the LUKS header itself.

† There is a lot of misinformation about archival DVDs out there, in part because "archival" is not a formal term and anyone can slap that label on their products. If you buy one, do your research first! Otherwise you may find yourself buying a sub-par product. In particular, be skeptical when "gold discs" are mentioned.


You have not given us enough information to determine if this is vulnerable to XSS. XSS occurs when a user input is displayed in a browser without proper escaping. For example:

$.ajax({
  $("#id").html($("#field").val());
 });

is vulnerable because the input value from #fieldis displayed in the browser without escaping.

If we look at your example:

$.ajax({
  url: "http://mywebsite/script?param=" + $("#field").val(),
  dataType: "jsonp",
  success: function(response) {
      $("#id").html(response);
  },
 });

a vulnerability exists if response contains all or parts of #field's unescaped value. If response can only contain constant strings such as OK and Error, or if there was proper HTML escaping done on the user input, then you are secure. Otherwise, you have a vulnerability.


With DNSSEC and DNSCurve, one can verify that a DNS response contains what the zone owner configured the authoritative servers to serve. The registrar and the parent zone owner can also produce valid DNSSEC signatures. But no one else can.

In a perfect world, everything would be signed with DNSSEC or DNSCurve, and everybody would run a validating resolver on each device, providing almost end-to-end security.

Unfortunately, this is not the case.

A usual scenario is that the local router has a built-in caching resolver, and all the devices connected to it just use that.

However, the local network is usually the network segment which is the most vulnerable to DNS spoofing. So, it's nice to have DNSSEC/DNSCurve verification on the router, but it doesn't prevent injection of fake DNS responses by someone on the same network as you. This is where DNSCrypt can help.

DNSCrypt is typically deployed using a pair of DNS proxies: a client proxy and a server proxy.
The client side of DNSCrypt is a proxy to which regular DNS clients can connect to. It translates regular DNS queries into authenticated DNS queries, forwards them to a server running the server DNSCrypt proxy, verifies the responses, and forwards them to the client if they appear to be genuine.
The server side of DNSCrypt receives DNS queries sent by the client proxy, forwards them to a trusted DNS resolver, and signs the responses it receives before forwarding them to the client proxy.

The DNSCrypt server can run on the router, along with a modern DNS resolver. Clients can then run the client code of DNSCrypt, leveraging the router DNS resolver.

    |----- Most vulnerable to attacks ------|            |-- Most vulnerable to censorship --|

         dnscrypt client               dnscrypt server
Laptop/workstation/phone/tablet --------> home router --------> ISP --------> the Internet

    |--------- Secured by DNSCrypt ---------| |------------- Secured by DNSSEC --------------|

Alternatively, companies, organizations and individuals are running public DNS resolvers supporting the DNSCrypt protocol. These can be used as an alternative to running a DNSCrypt server and a DNS resolver on the router. If your ISP is doing DNS-based censorship, this is a way to bypass it (but in that case keep in mind that the 3rd-party DNS resolver you use can still log all your queries).

All you need to use them is a DNSCrypt client such as dnscrypt-proxy or Pcap_DNSProxy. This will make sure that responses you received are the same as what the 3rd party DNS resolver you are using initially sent. However, these responses might not be the correct ones. It's just what these services decided to send to you, not necessarily what the owner of the zone you are querying published.

Some VPN services run their own DNS resolvers, accessible over DNSCrypt, in order to mitigate DNS "leaks". Since you already trust them for tunneling all your traffic, it cannot hurt.

The DNSCrypt client can run on every client device:

    |----- Most vulnerable to attacks ------|            |-- Most vulnerable to censorship --|

         dnscrypt client                                                                                dnscrypt server
Laptop/workstation/phone/tablet --------> home router --------> ISP ----------> the Internet --------> public DNS resolver

    |----------------------------------- Secured by DNSCrypt -------------------------------------------|
                                                                              |--- Secured by DNSSEC ---|
                                                                     |--- Most vulnerable to logging ---|

Or if you totally trust the local network, the DNSCrypt client can run on the router instead:

    |----- Most vulnerable to attacks ------|            |-- Most vulnerable to censorship --|

                                        dnscrypt client                                                  dnscrypt server
Laptop/workstation/phone/tablet --------> home router --------> ISP ----------> the Internet -------->  public DNS resolver

                                            |------------------ Secured by DNSCrypt --------------------|
                                                                              |--- Secured by DNSSEC ---|
                                                                     |--- Most vulnerable to logging ---|

Finally, you can run your own DNSCrypt server on a remote, trusted network, to get the best possible protection against censorship, while having full control over what the resolver is logging:

    |----- Most vulnerable to attacks ------|            |-- Most vulnerable to censorship --|

        dnscrypt client                                                                                dnscrypt server
Laptop/workstation/phone/tablet --------> home router --------> ISP ----------> the Internet --------> private DNS resolver

    |----------------------------------- Secured by DNSCrypt -------------------------------------------|
                                                                              |--- Secured by DNSSEC ---|

So, which one do you need?

They are complementary, and address different things.

If you are running your own caching resolvers, having them support DNSSEC and DNSCurve validation is an excellent thing. Unfortunately, as of today, the number of domains signed with DNSCurve is close to zero, and the number of DNSSEC-signed zones is growing pretty slowly.

For all the zones that aren't signed, DNSCrypt cannot protect everything, but it will at least protect the few hops between your client devices and the DNS resolver, which is better than nothing. It also runs on a different port than regular DNS traffic (443 instead of 53), which is enough to bypass some content filters.

But if your primary concern is privacy, what you need is a VPN.


"john --format=md5" caused "Unknown ciphertext format name requested" error

What version of your John?

kali@kali:$ john | head -3
John the Ripper 1.9.0-jumbo-1 OMP [linux-gnu 64-bit x86_64 AVX2 AC]
Copyright (c) 1996-2019 by Solar Designer and others
Homepage: http://www.openwall.com/john/
kali@kali:$

For version 1.9, there are a few types of md5. md5 only are not one of them.

kali@kali:$ john --list=formats | tr , '\n' | grep md5
 md5crypt
 md5crypt-long
 asa-md5
 dmd5
 krb5pa-md5
 net-md5
 md5ns
 pix-md5
tcp-md5
kali@kali:$

If you're not sure of your hash type, use hashid tool

kali@kali:$ hashid '$1$FTpMLT88$VdzDQTTcksukSKMLRSVlc.'
Analyzing '$1$FTpMLT88$VdzDQTTcksukSKMLRSVlc.'
[+] MD5 Crypt
[+] Cisco-IOS(MD5)
[+] FreeBSD MD5
kali@kali:$

This is actually MD5 Crypt

kali@kali:$ cat hash.txt
$1$FTpMLT88$VdzDQTTcksukSKMLRSVlc.
$1$wk7kHI5I$2kNTw6ncQQCecJ.5b8xTL1
$1$7d.sVxgm$3MYWsHDv0F/LP.mjL9lp/1
kali@kali:$

Try again ... voilà

kali@kali:$ john --format=md5crypt hash.txt
Using default input encoding: UTF-8
Loaded 3 password hashes with 3 different salts (md5crypt, crypt(3) $1$ (and variants) [MD5 256/256 AVX2 8x3])
Will run 2 OpenMP threads
Proceeding with single, rules:Single
Press 'q' or Ctrl-C to abort, almost any other key for status
Almost done: Processing the remaining buffered candidate passwords, if any.
Proceeding with wordlist:/usr/share/john/password.lst, rules:Wordlist
Proceeding with incremental:ASCII


HSTS Strict Transport Security: Include base domain

Its not an ugly way. But a better way will be to use the preload system : https://hstspreload.appspot.com/


Why are CA-issued certificates considered so much more secure than self-signed certificates

CA signed certs are not actually more secure than self-signed certs, in the sense that the level of encryption is the same. But there is a big difference in the level of trust between the two. Visitors to a site using a self-signed cert have to trust that the cert was generated by the site owner, simply because the site says it is. There is no easy way to discern if there is currently a man-in-the-middle attack happening. With a CA signed cert, now the user can trust that both the site and a 3rd party are in agreement that the cert was generated by the site owner, so a man-in-the-middle attack would be much more difficult to pull off.

Note: the original question has since been edited; the following statement applies to the previous wording but I'm leaving it here because it is still informative:

  In your question you claim that some CAs will issue a signed cert
  without making sure you own the domain. If that were true, then
  perhaps there would be some validity to your assumption that certain
  CA certs are not more trustworthy than self-signed. Fortunately
  though, it is not true that any widely trusted CAs will issue a signed
  cert without verifying you own the domain. In your comment you mention
  that the verification may be as simple as receiving an email, and you
  question the security of that.

I think it is good to question how secure receiving an email is, but you must admit that receiving an email is entirely different than no verification at all. You do have a point in implying that the trustworthiness of those cheaper certs may not be as high as other validation levels, (which might include installing a code on the web server), and that's why there are different levels of validation. Arguably though, since most visitors do not inspect the certs, perhaps the more expensive certs are really not much better than the cheapest ones, with the exception of the most expensive "green bar" EV certs.

So, in a sense, I agree with your implication that perhaps the minimum standard for obtaining a CA signed cert should be raised to beyond simply receiving an email, but as it stands today, this is what we have, and it's still much better than nothing.


With most TLS implementations you just need to store the self signed certificate of the server in the trusted certificate store. You may have to add a specific option to the command line or API call to mark the certificate as trusted.

In that case the chain of the server certificate leads to a trusted certificate because the server directly uses the trusted certificate (i.e. a "chain" of one certificate).

You do need to establish trust before establishing the connection, e.g. by distributing the self signed certificate with your client application.


What is the difference between ARP and ICMP MITM attack?

Firstly, ARP is a protocol used in a LAN to resolve the MAC address of the next or final destination IP. Therefore an ARP MITM attack works by spoofing a MAC address within a LAN in response to a victim's ARP request. If the MAC of the intended machine is successfully spoofed with the attacker's machine, then the victim will send traffic to the spoofed MAC address instead of the destination MAC address. It follows that for this attack to be successful, it must be executed within the victim's LAN. Additionally, for an ARP spoof to be effective you have to be able to respond faster than the actual destination ARP response.

An ICMP MITM attack on the other hand is accomplished by spoofing an ICMP redirect message to any router that is in the path between the victim client and server. An ICMP redirect message is typically used to notify routers of a better route (see http://www.cisco.com/c/en/us/support/docs/ip/routing-information-protocol-rip/13714-43.html), however it can be abused to effectively route the victim's traffic through an attacker controlled router. While this attack does not require LAN access, the disadvantage is that many routers have static routes or do not accept/process ICMP redirect packets.


How is ECIES available in FIPS Validated libraries?

It is possible for a module to be FIPS 140 Validated and include non-validated features like ECIES. You can see multiple instances of this in various validation documents:

Blackberry
Validated FIPS 140-1 and FIPS 140-2 Cryptographic Modules (2013) (includes BSAFE)

The trick is that to use those modules in a FIPS-compliant way, you need to only use the validated algorithms. For instance, in the BlackBerry document:

  ... ECIES ... encryption algorithm are supported as non FIPS Approved
  algorithms. In order to operate the module in compliance with FIPS,
  these algorithms should not be used.

This is backed up by the NIST Guidance :

  NOTE2: The operator of a cryptographic module is responsible for
  ensuring that the algorithms and key lengths are in compliance with
  the requirements of NIST SP 800-131A.

So, although a module can be FIPS 140-2 validated, the onus is on the operator to ensure that how it is used is in compliance with the current standard. With that understanding, the maker of a module can include non-FIPS-validated algorithms for other purposes.


How can I make sure the mic input of my laptop/computer/cell is not secretly scanned for keywords and sent to the government?

In order to combat a roving bug you can install a switch to disable your microphone.


I get a javax.net.ssl.SSLHandshakeException but my colleague does not, what could this mean?

If the SMTP server is using a self-signed certificate and you did not import the certificate as trusted this exception would be the expected one and something would be wrong (insecure) with your code if you would not get such an error. If instead the certificate should be signed by a public CA it might be a problem that you don't trust this CA in your code for some reason (unlikely), that you get a different CA then was sent by the server (i.e. SSL interception) or that the server is not properly setup and might be missing a chain certificate.

If it works for your colleagues you need to check with them what they do different. It might be that they get a different certificate then you if they have a different network connectivity (i.e. one without SSL interception vs. one with SSL interception). It might also be that they've explicitly imported the relevant certificate as trusted. Or it might be that they explicitly ignore certificate errors in their code. And while ignoring certificate errors is usually a terrible idea since it makes man in the middle attacks undetectable, it is still a commonly recommended workaround  by users which don't understand or don't care about security.


What are the risk associated with granting full permission (Any) to DB Admin users to the Database?

It always comes down to the same thing, the principle of least privilege.

Why would you want to give anyone more permissions than necessary to perform his or her job efficiently? It's just unnecessary risk. Sure, you may have logs in place to track all the actions taken by a particular administrator, but who is going to monitor those logs? How will logs help you if a rouge admin steals your confidential data or drop your production database in the middle of the day? Sure, you can track who did what but the damage has already been done.


How does one monitor published vulnerabilities in a small development team?

At scale, it's best to continuously vet your automation, but the most-important part: automation

For RHEL, CentOS, Fedora, et al there's yum-cron. You can even specify security-severity:Critical if you only want critical patches.

For Debian, Ubuntu, etc there's unattended-upgrades with similar concepts.

If you build applications or install custom apps, ensure you are covered there as well. Additionally, there's infrastructure to ensure patching. Automate it as much as possible. People will argue that this can break things. That's why I recommend you automate as much as possible -- but not so much that you break things. If you are only automatically installing critical security patches, then you are way less-likely to break things. Figure out how to automate it at least that much. Even if you have a policy to not directly automate without human approval -- automate gathering all of the information, download the patches, and have a push or pull mechanism, hair-trigger ready-to go.

OWASP has a lot of great integration capabilities via Dependency Check -- with even a web interface for it through this project -- https://www.owasp.org/index.php/OWASP_Dependency_Track_Project

One can integrate similar concepts to build servers and continuous-integration / continuous-deployment projects very easily. These environments are heavily-equipped for exactly this sort of automation. Many commercial solutions also exist -- it's easy to find them online.


Revocation really is cancelling the certificate issuance -- the CA which has signed the certificate announces that it now denies it. A root CA being self-issued, it cannot be revoked. A root CA, by definition, is trusted a priori, not because its certificate was signed by some higher-placed CA in the hierarchy. Thus, there is nobody to emit revocation information that would be authoritative on that CA.

Some extra comments must be made, though:

You do not revoke a CA; you revoke a certificate. Any entity that has a name and owns a key pair, in particular a CA, may own several certificates. Each certificate is an assertion of that key ownership. What you think as a "root CA" may also be an intermediate CA in the following sense: besides its self-issued (traditionally self-signed) certificate, it may also have obtained another certificate that contains its name and its public key, and issued (signed) by another CA. The latter certificate, being issued by a distinct CA, can be revoked. This kind of situation is common in case of "root CA renewal" (a new root CA is created, and "cross-certificates" are issued so that the transition is smooth).
What certificates cannot do, maybe other systems can. For instance, a Web browser may contain a list of a priori trusted root CA (for validation of SSL server certificates); then, any update of the browser executable may add or remove root CA. There is no CRL involved, but it sure looks like a revocation mechanism, especially since modern browsers update themselves automatically. Windows has a similar system with a "disallowed" certificate store that acts like an OS-enforced, super-CRL which can make any certificate untrusted, even root CA certificates explicitly added to the store of trusted roots.

Trying to make a CRL containing the serial number of the compromised root, as was suggested in another answer, will not have the intended effect, for two reasons:

Systems that validate certificates (e.g. SSL clients when trying to verify the server's certificate) download CRL only for certificates where it makes sense, i.e. not for root CA, since they cannot verify the signature on the CRL save relatively to the public-key of the CA higher in the chain, since there is no such CA. You can write what you want in any CRL; if clients don't look at it, it won't get you far.
Even if you could somehow convince a client to download that "suicide CRL", where the root CA kills itself, remember that the private key have been compromised, thus the key thief may produce and sign a counter-CRL that says that everything is fine and nobody is revoked. Since the CRL download cannot be otherwise protected, the attacker can prevent that self-destruction mechanism to happen, even assuming that it would have worked with existing clients (and it does not).


How can I be attacked by opening a corrupt MS Office document?

There are many reasons to why a corrupt MS Office document could attack your computer when it is opened.  The first reason is Macros, which is typically coded in Visual Basic.  The code of the macros could have malicious outcomes.

Although macros are majority of the time the cause for attack to occur from opening an MS Office document, there are other things as well.  Another major attack vector from corrupt or malicious MS Office files are ".pst" files.  PST files are files that contain archived calendar, messages, emails, etc. from MS Outlook.  From just the name of the office product one can just guess what the attack vector is.  The attack vector being that if a malicious email that had an internal malicious JavaScript, image, etc., was archived. Later opening up the ".pst" file and opening the email, it could start attacking the device that is opening the archived email in the ".pst" file.

Another attack vector (although old) is a malicious ".xll" file.  A ".xll" file contains C, C++, ".dll", and FORTRAN executable code that could be malicious.  A ".xll" file is considered by MS as a legacy Excel format now.

The last thing I can think off is a malicious ".maq" file that is used by MS Office.  It is a regular shortcut, but when opened it can automatically run a query on a database preconfigured or specified in the query.  If the query is malicious (ex. DROP DATABASE PASSWORDS), it will be attacking, or should I say modifying the data in the database machine/environment.


Must the different multi-factor "factors" be correlated if possible?

In some cases of system design, you might be able to get away with blindly accepting tokens, but I doubt it.

Any security control is meant to address risks. If you want to use both a certificate and a separate credential set to authenticate a server, then you do that because it reduces the risks identified.

If you do not correlate the certificate to the credential set, then you reduce the factors to 1.5 instead of 2; any combination will do.

Is this ok? It depends on the risks that you want to reduce. If it does not matter, then it does not matter.

Here's my problem though. If a threat actor has access to the certificate, then the actor can also gain access to the credentials, and vice versa. I'm not sure how adding a factor is a control in the situation, but I also do not know your risk scenarios.


Storing password hashes without a correlation to the user account

Maybe I don't understand but if I were an attacker I would do the following:

I would steal both tables.
Then I would select a user I am interested in (e.g. an administrator) and start hashing passwords using his salt and look if the resulting hash is to be found in the hash table.

So what's the difference? (except that I have to lookup if the computed hash exists instead of just comparing (DB servers are good at such tasks)

P.S.: The author also argues that the size of the table might make it harder for the attacker to steal it. That's a good point. (Unless he doesn't steal it but runs the lookup queries on the site's DB servers)

It is an interesting idea that should be topic of more (academic) research.

P.P.S.: The author suggests a method to fix the hidden backdoor problem here. On first impression this seems to fix it.


What is the simplest way to prevent adding a new default route via dhcp?

If you can change openvpn configuration you can add, instead of the default route, the following two routes:

0.0.0.0/1 via tunnel
128.0.0.0/1 via tunnel

In this way the kernel always choose the /1 route because it has a longer subnet mask.

It's a workaround, but in many cases it works.

OpenVPN even has an option to do this: add def1 to the redirect-gateway configuration entry or flag.


Security is a function of alertness (also = paranoia at some level) - so it's nice that you practice security all the time even when it's your home network.

How can I tell if my router implements DMZ correctly?

Options:

Audit the router in question. It usually needs so much effort that might put this in "disproportionate effort (to benefit)" category. Works nicely if your day job involves auditing network devices, coz you're already half-way there on TTPs.
Setup an IDS with good exception analysis and hope to catch it if/when the router screws up; and then investigate to find out where/how it failed. Needs more resources (esp., time & patience) - but it'd be my choice coz it's more practical. We need the detection capabilities anyway.

If it is implemented correctly, is it something I can trust to keep my home network completely isolated from a compromised device?

Within reason - subject to your confidence in "if implemented correctly", yes. I'd still say trust but verify (healthy skepticism?) - so setup some level of detection capability if you can.

Am I over-rating the dangers of exposing a single port? Are there better ways of allowing remote access from a single remote IP?

Short answers - Yes (over-rating dangers) and May be Not (whitelisting an IP address is usually good enough).

Let's think like an adversary who might target you. When reasonable steps are taken at the network level, it is much simpler to try to compromise you / your server through other methods than try to hack through the infra.

So in this setup, I'd say your risks are more likely to be (than not):

human compromise (phishing + keylogger on whitelisted endpoint)
higher / app layer vulnerabilities (in the gaming stack) that your whitelisting should still protect against, unless the vector involves your whitelisted remote endpoint.
a zero-day on your router + higher layer vuln + ... It's not unusual that big hacks need multiple exploits chained together... so that's what you're looking at.

It's a good situation to be in - that an adversary needs multiple exploit chains and maybe burn a zero-day or two to get at you. Even better - when after all that, you detect the adversary quickly and react to thwart any impact. This is where your strong detection/response kung-fu serves well.


Is checking against password lists a good way to enforce a secure password policy and possibly detect dictionary attacks on a web-based app?

If you are concerned about them using weak passwords, I would just focus on the complexity requirements. Force them to use a 12+ character password with special characters. A list of 65 million sounds to be relatively small, are these mostly less than 8 characters?

In consideration of a brute force attack, it doesn't matter if there is great entropy or distribution among the characterset if the length is low (8 or less characters).

You get the same bang for you buck if you just enforce client side length and complexity or "password strength checker". Probably better to put your effort into securing the storage of the password on the backend (salt, pepper, hsm, etc.) so it can't be compromised.

From the brute force perspective. If the attacker steals your DB and does an offline attack, clearly your check if not going to be of any consquence. If they are trying to do an online brute force, you can just lock the IP out after X number of failed attempts or to lock out the account if its being targeted with multiple attempts in a distributed matter and let the user reset when they want to legitimately get on. It sounds like it would be much more complex and require more resources to check against the list on each attempt to logon - possibly could lead to a denial of service on a modest web server by over taxing the system.

While it can have some value, I am not sure if users would get it. While its nice to want to try to protect them, if they want to use short passwords and you let them, they will - maybe they take their five character password and add a number - if this isn't on your list, its done nothing to help them since it's a still only six characters. So your list will detect some common passwords, but it doesn't address the core issue which is length and complexity. Trying 65 million passwords in an offline attack is no effort for an attacker with a GPU cracking rig.


When implementing CSRF protection, one generally uses a CSRF cookie that must be included in the body of the request. This prevents CSRF attacks because the malicious website cannot read the other website's cookies.

This is fundamentally incorrect.  I think you misunderstand the attack vector.

A CSRF attack (also called "session riding") will typically look like this

Hacker sends a carefully crafted email to millions of users, and/or tricks them into opening a carefully crafted page of the attacker's design.
Of those millions, a few users will access the email while their browser is already logged into a secure web site, and hence has the session cookie
A clear GIF, link, or script in the email or malicious page targets a location within the secure web site
Because the user is already logged into the site, all cookies associated with that site are automatically sent along with the request.  Hence the attack can "ride" on top of the user's legitimate session.
At no point does the attacker learn what is IN the cookie.  He is just borrowing it, blindly.

A CSRF mitigation relies on the fact that the attack is crafted ahead of time and has no ability to access the content of any of the secure pages (it can only issue a request blindly).  A CSRF token is included as a hidden variable in the site's secure pages; when the attacker's request hits the site, yes it has the cookie, but it will not have the hidden variable.  The site can validate the cookie against the variable, and if the variable is missing or wrong, the request is denied.

It is certainly possible to implement a CSRF mitigation using some token in the URL (in addition to, not in place of, a cookie), but this approach has certain problems.  In order to offer any security, the token must change occasionally (sometimes per session, often per page request) and when it changes, it will invalidate any of the user's bookmarks.  Also, it is darned ugly because an end user can see what appears to be goobledigook in the address bar.

You should NOT implement a cookieless mechanism that relies on the URL token alone, as this causes other security problems.


Cryptographically secure voting is difficult because voting encompasses so much. Let's take, for example, vote-buying or coercion.

Imagine a system where I can vote, and can verify that my vote was tallied correctly. Now I can provide that proof to a third party who purchased my vote to claim renumeration for that vote.

If the voter cannot verify their vote was tallied correctly, then how can the voter be sure that the authorities counting the vote are not corrupt, and deliberately mis-counting votes?

As it turns out, when you really get into the nitty-gritty of cryptographically secure voting systems, these sort of issues are found all over the place. Arriving at a consensus for a system of governance is inherently a social problem, and technical solutions almost universally fall short of helping in any large, meaningful way.

Further, there is the issue of the hardware and software platform. Many companies have attempted to produce "secure" voting platforms, but inevitably, they have shown to be weak to simple tampering attacks, or even just buggy to the point of uselessness. There's no time to deal with a batch of bad machines or fix a software bug when the election is held on a single day.


If I turn off Windows Defender Credential Manager off in Windows 10 so I can run a virtual machine in Virtual Box, is that a bad idea?

The feature you named does not exist. What you're actually asking about is Windows Defender Credential Guard. This feature moves your passwords and derived credentials for Kerberos and NTLM used to communicate with services on the network into a separate secure virtual machine (VSM).

The point of the feature is to make it more difficult for attackers to steal credentials and move around an enterprise network. If this feature is turned off an attacker can easily grab these credentials and potentially elevate their privileges on the network.

Since this feature is not on by default and only applies in Active Directory-based networks it's likely it was your administrator(s) that turned it on. If that's the case you should be asking them if it's unsafe to turn it off.


Do actual penetration testers actually use tools like metasploit?

As far as forensics is concerned, Metasploit have payloads which are specifically designed to make the work of forensic analysis more difficult. For example, the most famous payload which is selected by default with a lot of exploit modules is the meterpreter payload. It completely runs in-memory and don't touch the disk for any operations (unless specifically asked by the user). Which means there will be no evidence in the prefetch folder or any other place on the disk.

You don't have to clear all the event logs. You can selective clear any event log you want through the meterpreter script event_manager.

Meterpreter has a tool called timestomp which can change the modification, access, creation, and execution time of any file on the hard disk to any arbitrary value. You can securely wipe out any file with the sdel (safe delete) module which not only securely wipe the file contents but rename the file to a long random string before the deletion which makes the forensic recovery of not only the contents but the file meta data very difficult as well.

Now comes to your second part of the use of Metasploit by actual malicious attackers in real world attacks. There have been reports that Metasploit was used in one of the attacks on the Iranian nuclear facility. The reason you don't see Metasploit more often is due the open source nature of the product. Since the exploits and payloads are available to everyone, by default every security product such as antivirus, IDS/IPS etc consider these files as malicious. The defense industry has gone to an extent that even if one create a completely benign file with Metasploit, it will be detected by almost all the AV solutions. Generate an empty payload like:

echo -n | msfencode -e generic/none -t exe > myn.exe

Upload it to VirusTotal and you will see that more than half of the AV solutions detect it as malicious. More details can be found on the Matt Weeks' blog here.

With this behavior no attacker will risk using Metasploit for actual attacks due to the very high detection rate. The modules can be easily customized and bypassing AV and other security controls through Metasploit is quite easy as well. However, at that point it is difficult to determine if the payload is written from the scratch or the Metasploit module has been modified. Therefore, it is difficult to say for sure how many attackers have used or continue to use Metasploit in their operations.


There are some problems I see with your approach.

Firstly, it provides a route to a denial of service attack; someone just needs to keep supplying bad passwords from an ip address to lock it out. Assuming a 1:1 correlation between users and ip addresses is a bit silly.

Secondly, in order to reset an account you need to delete data which is useful in terms of an audit trail. Were you planning on reseting the account after a successful login?

Thirdly, it does not protect against a distributed attack - or one with spoofed addresses.

If it were me, I would go with....

SELECT SUM(score)
FROM (
   SELECT COUNT(*) * ipweight AS score
   FROM logins
   WHERE failed=true
   AND ip=INET_ATON(*client_address*)
   AND ip <> *trusted_device*
   AND timestamp>NOW - INTERVAL *config_value* MINUTES
   UNION
   SELECT COUNT(*) * acctweight AS score
   FROM logins
   WHERE failed=true
   AND username=*supplied_username*
   AND ip <> *trusted_device*
   AND timestamp>NOW - INTERVAL *config_value* MINUTES
   UNION
   SELECT COUNT(*) * allweight AS score
   FROM logins
   WHERE failed=true
   AND ip <> *trusted_device*
   AND timestamp>NOW - INTERVAL *config_value* MINUTES
)

(This can be extended with other atrributes such as user agent)

Set a lower threshold than the lockout at which you require the user to complete additional verification (such as a capcha).

Just log the attempt (ip address, username, timestamp, outcome) in the database (not the lockout time).

Note that representing the ip address in its native (integer) format in your database is almost always a good idea. Here it offers the opportunity of aggregating failures across an arbitrary netblock.


Share a public key from an app to verify authenticity of data submitted

Question 1

MiTM types of attack can be easily avoid by implementing encryption and digital signature. Since you are encrypt and sign the data being send, and assuming client's device is not compromised, it is fair to say even the data was altered, you will know it if you implemented those thing right. You can harden your system by using TLS plus public key pinning, that way, even someone wants to intercept, the client will know because the certificate is different.

Question 2

You can't do much about it if you only use asymmetric cryptography and digital signature, for more details, look at https://security.stackexchange.com/a/31032/58501. However, if you willing to ask the client to type in a OTP which the master key will only know by both parties, and exchanged in a secure way. You can detect such attack even the private key is leaked since the OTP can change over time or by increasing counters, depend on which OTP you use. Take a look at RFC 4226 and RFC 6238 to get some idea from it. Note, the OTP generating machine should be differ than the communicating device, and no connection between them.

Question 3

It depends on what computer language you're using, you can try find an OpenPGP API or framework, this is the only software I know it can do what you want without much knowledge(it still require some learning, not as much as doing it from ground up). If you can't, you're out of luck since doing cryptographic stuff in a correct way requires a lot of steps and long time learning. E.g. you should encrypt the data first, then calculate the hash of it, sign it with the private key, pack all the stuff in one package, finally sent it to the server. These steps are mostly separated in a framework which you need to call each of them individually.


Security in transferring sensitive data over web apps

Ever heard of RSA?
Much more safe and much more simple.
Every client generates an private key and sends its public key to the server.
The client that starts a group generates an AES key for encrypting group files and decrypts the key with each public key of the other members. Than it sends the encrypted keys to the other members. They use their private key to open the group key. Now they all now the group secret and can exchange data secretly. 100% secure and simpler as it sounds


Could always-listening mobile apps secretly spy on conversations?

Users can only rely on the word of the distributor of the app, which has proven problematic recently.

There is no easy way to technically prove, that no audio is recorded, analyzed or transmitted.


Can deliberately low-entropy hashes be used to prevent dictionary attacks?

You said that you allow ''X'' to have false-positives. Therefore you can simply strip much entropy and allow false-positives, but attacker would face same problem if he got your database.

But if ''X'' has enough entropy on it's own (128-bit or 256-bit), attacker won't be able to get any more information from hash (for example using SHA-256 or SHA-3), and you wouldn't have false-positives. Hash would exactly only allow this one information - is new information I got same as this one.

If your ''X'' doesn't have enough entropy and/or you accept risk of having false-positives, then you can cut on your hash too (then it becomes how many false-positives you accept to have).

On the other hand when using bcrypt and other PKDF, I find that you will quickly lock yourself out of the information. Assuming information ''a'' was to arrive to you, you had no other choice than to iterate over every bcrypt hash stored and check if it is ''a'', which (as PKDFs are slow) would be inefficient to check.

Also, remember that weak point of system that only passes some confidential information is an active attacker - then he can simply store every ''X'' your service got since it was hacked.


You should look into the HTML5 Sandbox options. While these are not supported in all browsers, they can be helpful to restrict certain actions the attacker might take, such as redirecting the user (replacing your page) rather than being contained in the iframe.

Thanks to Same Origin Policy, JavaScript and other plugins should stay fully contained within the iframe.

Obviously there is the risk of a vulnerability in the user's setup. This is more likely in a plugin than with JavaScript. However I believe the risk difference there is quite small when comparing iframe vs redirect as you are asking. I would say that redirect (or popup window) is ever-so-slightly safer.

Ideally, you only allow such redirection or iframing to your Partner, and not to 'any random site'. Less-tech-savvy users are more easily tricked into downloading malware from tricky malicious sites. If you only allow a select set of sites (i.e. just partners as you say) then you are less likely to be accidentally guiding users to such tricksters.

@paj28 makes an excellent comment:

  With an iframe, the browser address bar still shows your site, so if an external site asked for a password, users would think they're telling your site the password, when in reality they're telling the external site.

This does not affect the Remember Password feature of the browser, but @paj28 is correct that users may not realize the presense of an iframe at all.

I would suggest that a header bar above the iframe be visible to clearly indicate that the visitor is on someone else's site, and to give them a convenient way to return to the safety of a page on your site.

As for redirect, while the URL bar would show the destination site (unlike iframe), it also gives the destination site full control of the site display (you can't include a header bar) so that might make it easier for them to phish the user's password, as many users rely on visual cues (i.e. an official looking header & logo) more than the URL bar.

Finally, I'd point out that well-known sites, before redirecting a user away, would provide brief announcement that it may be unsafe. I personally find such notifications annoying, but it may help from a security standpoint.


If a host has a single port that is connected to many remote hosts and this single port has a big port number (for example 50000 TCP/UDP port) and the same thing is true for destination ports, then most probably the mentioned host uses a BitTorrent client. This method can eliminate all p2p connections, not only BitTorrent.

In your case you may be interested in this topic:
Can BitTorrent Clients be Fingerprinted?


Why do some websites increase the number of characters in the password field when logging in?

Some online banks, and some other web services, clear the password field and/or replace with a fixed number of characters so that if (for any reason) the login form submission failed or the user double clicked on the Login button then he won't be able to make the same submission again. The "rationale" behind it seems to be that they don't want the password to stay in the user's browser for more than needed.

To me, it actually doesn't make sense at all. But, then again, some online banks enforce a number-only password policy, which doesn't make sense at all.

This is usually done using JavaScript, something along the lines of

loginForm.elements[3].value = '00000000000000000000000000';


It depends.

The kernel can use swapfiles as backing store for a tmpfs filesystem: if the kernel decides that it needs to swap out something to free up physical RAM, the contents of the filesystem are candidates for swapping out, either in whole or in part.  If you're lucky (or unlucky), coherent pieces of data will wind up in the swapfile for an investigator to see.  Even if parts of the filesystem get swapped out, though, recovering data will be difficult: since the filesystem metadata may not be present and data may be in random order, it's more akin to performing forensics on a memory dump than on a filesystem.

If the computer is still running with the filesystem mounted, it may be possible to perform a DMA attack to recover the contents of RAM.  In this case, forensics will be easy, particularly if the swapfile can also be dumped, because the entire structure and contents of the filesystem is accessible.

If the data does not get swapped out and a DMA attack is not possible, the only option is a cold boot attack to try to recover the contents of RAM before it decays.


How does X-UIDH user tracking work and how can I detect it?

Somehow I ended up on your question when googling for something else. Anyways:

Here is a website to test for the header: http://uidh.crud.net/ .

Verizon achieves this (adding the header info) by what is essentially a man in the middle attack on all HTTP traffic on port 80. Since they control the ingress and egress of your unencrypted data, it's pretty easy to modify the HTTP header information. That are tools out there, like fiddler for Windows, or any proxy server, that you can use to do the same thing to HTTP traffic.

Here is another site that will show you all the header information coming in your HTTP request upon arrival: http://browserspy.dk/headers.php .


If the client generates the RSA keypair, signs it using the certificate, and sends it to the server, what stops a MITM from doing the same thing?

That does not happen. If the server have a CA-issued certificate, the client will know for sure that the certificate belongs to the server. If an attacker creates a fake certificate, it won't be signed by a valid CA and will be invalid.
When the client receives the certificate, it checks the signatures on it, and who is the CA issuing it. If the CA is not trusted, the certificate is not trusted either (and the client issues the error sun.security.provider.certpath.SunCertPathBuilderException:  unable to find valid certification path to requested target or something similar).
The attacker could connect to the server, receive the certificate, and generate its own AES keys, but that would be useless in any MitM scenario, as his keys aren't the ones the client uses, so they cannot decrypt anything.

Isn't it safer to generate a new keypair for each connection, or do I actually use this particular key? What am I missing about the standard pattern for TLS?

You are missing quite a lot. The RSA key cannot change on every connection, unless you want to issue a new certificate, send it to the CA to sign it, install it, and repeat that for every single connection.
TLS have some complexity on it, but the over-simplified ELI5 version is:

client connects to the server and gets the certificate

client sends a random key (the client key), and all ciphers he supports

server responds with a random key (the server key) and the cipher he will use

at this point, the session is established and secure

There's more details on this, but is basically that. The server certificate have the server RSA key, the issuer (the CA), the subject (the servers it is valid for), the validity (expiration date), and the client uses that information to decide if it trusts the certificate or not.
So use TLS, don't bake your own crypto. TLS is around for a lot of time, is battle-tested, have extensive documentation, libraries, and examples available, and it's easy to any programmer to inherit the project later and keep going.


Security concern to implement a web based remote desktop

Lots of questions here.

How you secure a connection depends on how much control you have over both ends (and the connection in between). There's lots of code and tools available to support TLS, so it's relatively easy to implement security using this - but there is a lot more overhead than, say IPSEC - but that's a lot more difficult to configure.

The problem with seperating the encryption layer is that you start losing control over the buffering / naggling - you want to get a near real-time response. Generally this would favour using UDP rather than TCP, however my experience using VNC is that within around 60ms distance it's still usable.

The big problem for this kind of application is getting your operating to talk to a virtual screen. The X Window system was always designed with this in mind - but for other user interfaces it can be a lot more complex.

A big question is whether the world needs another remote display protocol - have you had a look at novnc? This requires no client other than a browser and uses VNC, hence all sorts of server (in the RDP/VNC sense rather than the X Window sense) are supported.

  how can I detect that the files is safe

Exactly the same way you check the fle is safe using any other protocol - quarantine files / convert them to a format which doesn't support embedding of malware.


From where I can get a list of trusted certificates fo HTTPS?

In any case, OCSP is not about telling you who you should trust; OCSP is solely concerned about revocation. When an OCSP server sends a response which says that a given certificate is "good", this is a misnomer; it really means "there is no known revoked certificate with that serial number". OCSP does not guarantee that the target certificate exists at all, let alone that it is "trustworthy".

That being said, the list of trusted CA is, indeed, the list of trusted CA. Will you declare that you will trust some CA because you found some list on some Web page which tells you that "you shall trust these CA", and that Web page was pointed to you by "some guy on the Internet" (who shows neither his real name, nor his real face) ?

If you really want to surrender your security to the advice of a random stranger, be he a bear, you may at least apply some personal judgement and decide on a per CA basis whether you want it or not. As a starting point, you could begin by copying the "trusted CA" from another Web browser, say Internet Explorer or Firefox. The CA from IE are the CA that Microsoft, in its infinite wisdom, declared fit to be trusted by the general public (the list and rationale about why these CA are "trusted" can be found there); you may want to prune that list a bit. However, Windows' market share being what it is, it is pretty much guaranteed that any HTTPS Web site which "works" will have a certificate issued directly or indirectly by one of these CA.

(Since the Microsoft list of CA contains a number of "government CA" which were added because governments are, as a rule, narcissistic, but are not actually used, the list can be considerably pruned without substantially breaking Web browsing. There may be about a dozen commonly used root CA.)


How can I intercept XMPP traffic on Android?

I guess set up a VPN-server of your own, connect your phone to it and intercept everything with wireshark could work given that you have the neccesairy certificates or are able to MITM yourself with a fake TLS certificate.

Alternatively one of the many tcpdump-alternatives for android for use with wireshark?


Is there any live ZRTP mitm attack demostrtion?

ZRTP protocol isn't secure because it can't be MiTM'ed. It is secure because a MiTM attacker can not easily predict when and how the short authentication string (SAS) exchange will take place during the conversation.

To successfully MiTM a voice call, an attacker has to know when and how the SAS exchange will take place, and then send synthesized voice packets to the users during the exchange. Moreover, the synthesized voices should sound like the actual voices of the users to successfully pull this off.

SAS exhange can take place during any moment of the conversation.
SAS can be encoded and spelled using a method that's previously known to the users (eg: NATO phonetic alphabet)
If it is a video call, SAS can be exchanged using sign language, or writing SAS on paper and showing it to the other user.

A good place to start would be RFC 6189 - ZRTP: Media Path Key Agreement for Unicast Secure RTP.


Work computer picking up on personal computer on home wifi?

While the answer below is generally correct, keep in mind that some websites track your browsing activity using sessions, and this data will be saved even if you change computers... The reason I think this could be important to you is that things like your search history using Google may be transferred to your work account if you use one account on both computers... Under normal circumstances, it should not be possible to view this data across the network - but it can be seen physically at your work place.

edit: the answer above is not precisely correct, the truth is - your data across the network is not separate at all, it's possible to see any data sent across the network even from a separate computer (albeit, some of it may be encrypted, ssl, etc...). Under reasonable circumstances, though, this should not happen in your case.


Apache naming for TLS_RSA_WITH_3DES_EDE_CBC_SHA

The "Apache naming" is actually the syntax used by OpenSSL. According to https://testssl.sh/openssl-rfc.mappping.html the OpenSSL name for TLS_RSA_WITH_3DES_EDE_CBC_SHA
 is DES-CBC3-SHA.


Remotely included script cannot set session variables

The included file is actually executed on your server, not on the vulnerable server when including it (which in this case is the same server, but it's still wrong behavior).

What is included is actually the result of the PHP execution ("test" in this case).

What you want is to return a file that actually contains the code. So you could either transform the hack.php file into hack.txt, or simply adjust the code to echo the desired payload:

<?php
echo '<?php
  session_start();
  $_SESSION[\'username\'] = "foo";
  echo "test";
?>';


Can I use HTTPS to pass a symmetric key used for encrypting TCP packets?

HTTPS is TLS. Using HTTPS you already establish a symmetric key as part of setting up the TLS connection. You don't need to pass yet another symmetric key around in most scenarios. You definitely should not be dealing with RSA or Diffie-Hellman directly. Just use a well-established crypto library supporting TLS/HTTPS connections. The only thing you need to consider RSA or DH or anything else is in setting up the configuration or calling parameters for your chosen library.


Does password protecting an archived file actually encrypt it?

Summary: yes, but use VeraCrypt instead.

From the documentation:

  WinRAR offers you the benefit of industry strength archive encryption using AES (Advanced Encryption Standard) with a key of 128 bits.

So yes, the data is encrypted. This is only one of the elements of security, however. Another important element is how the key is derived from the password: what kind of key strengthening is performed? The slower the derivation of the key from the password, the more costly it is for an attacker to find the password (and hence the key) by brute force. A weak password is toast anyway, but good key strengthening can make the difference for a reasonably complex but still memorable password. WinRAR uses 262144 rounds of SHA-1 with a 64-bit salt, that's good key strengthening.

An academic paper has been written on the security of WinRAR: On the security of the WinRAR encryption feature by Gary S.-W. Yeo and Raphael C.-W. Phan (ISC'05). Quoting from the abstract (I haven't read the full text, it doesn't seem to be accessible without paying):

  In this paper, we present several attacks on the encryption feature provided by the WinRAR compression software. These attacks are possible due to the subtlety in developing security software based on the integration of multiple cryptographic primitives. In other words, no matter how securely designed each primitive is, using them especially in association with other primitives does not always guarantee secure systems. Instead, time and again such a practice has shown to result in flawed systems. Our results, compared to recent attacks on WinZip by Kohno, show that WinRAR appears to offer slightly better security features.

The advantage of using the encryption built into the RAR format is that you can distribute an encrypted RAR archive to anyone with WinRAR, 7zip or other common software that supports the RAR format. For your use case, this is irrelevant. Therefore I recommend using a software that is dedicated to encryption.

The de facto standard since you're using Windows was TrueCrypt. TrueCrypt provides a virtual disk which is stored as an encrypted file. Not only is this more secure than WinRAR (I trust TrueCrypt, which is written with security in mind from day 1, far more than any product whose encryption is an ancillary feature), it is also more convenient: you mount the encrypted disk by providing your password, then you can open files on the disk transparently, and when you've finished you unmount the encrypted disk.
Sadly TrueCrypt is no longer in active development but it's successor VeraCrypt is. VeraCrypt is based on TrueCrypt and is compatible with the old TrueCrypt containers.

  Out of curiousity can what someone writes in their journal be used to incriminate someone in court?

This depends on the jurisdiction, but in general, yes, as they say in the movies, anything you say or write can be used against you. You may be legally compelled to reveal encryption keys, and may face further charges if you refuse.


Using a good password manager that generates unique, long, random passwords is a good idea. The passwords are not "stored in strings or encoded". They are encrypted, hopefully with a strong encryption algorithm like AES.

The encryption key is usually generated from the master password with an algorithm such as PBKDF2, specifically designed to be slow so as to prevent brute forcing.

Someone who does not know the master password cannot generate the encryption key, and therefore not decrypt the passwords.


With GPG, can you "decrypt" a file that hasn’t been encrypted?

Difference between signing and decrypting

I think your confusion stems from the fact that signing is in theory indeed somewhat similar to decryption for some algorithms (for example RSA).

Wikipedia for example phrases it like this:

  Suppose Alice wishes to send a signed message to Bob. She can use her
  own private key to do so. She produces a hash value of the message,
  raises it to the power of d (modulo n) (as she does when decrypting a
  message), and attaches it as a "signature" to the message.

This is however not how it is done in practice, and it is why your approach doesn't work.

For a more in-depth explanation of signing and decryption see eg here:

  In the abstract world of textbooks, RSA signing and RSA decryption do
  turn out to be the same thing. In the real world of implementations,
  they are not. So don't ever use a real-world implementation of RSA
  decryption to compute RSA signatures. In the best case, your
  implementation will break in a way that you notice. In the worst case,
  you will introduce a vulnerability that an attacker could exploit.

  Furthermore, don't make the mistake of generalizing from RSA to
  conclude that any encryption scheme can be adapted as a digital
  signature algorithm. That kind of adaptation works for RSA and El
  Gamal, but not in general.

Regarding PGP, it doesn't sign the message itself, but instead it signs a hash digest of the message:

  PGP uses a cryptographically strong hash function on the plaintext
  the user is signing. This generates a fixed-length data item known as
  a message digest. (Again, any change to the information results in a
  totally different digest.)

  Then PGP uses the digest and the private key to create the
  "signature." PGP transmits the signature and the plaintext together.
  Upon receipt of the message, the recipient uses PGP to recompute the
  digest, thus verifying the signature. PGP can encrypt the plaintext or
  not; signing plaintext is useful if some of the recipients are not
  interested in or capable of verifying the signature.

Here is an image describing the process:

Why you can't just decrypt a message to sign it

The above is all well and good, and we know that we shouldn't decrypt messages to sign them in practice, but why can't we do it just for fun?

Because that's not how PGP or GPG work. A full explanation of the inner workings would probably be too much for this question, but see for example How does GPG verify succesful decryption?.

In short, PGP doesn't just do some mod operation on the data on decryption, the .pgp format is well defined and contains various information. Note also that PGP doesn't actually use asymmetric encryption such as RSA on the message itself, but on a key which is then used to symmetrically encrypt the message.

Conclusion

To summarize, if you were to use plain RSA, you could use decryption to sign a message (but you shouldn't), but PGP and GPG aren't plain RSA, so you can't just decrypt a message to sign it.


cracking krb5 passwords (des3-hmac-sha1 and des-cbc-crc )

John the Ripper has community-supplied patches that appear to help with this.  For example, see:

A discussion on the John mail list
The bleeding-jumbo branch of John the Ripper's Github repo, including README-krb5-18-23 and the Kerberos modules in src.


What matters is the respective abilities of Alice and Bob with regards to storage. In your case, you assume that neither Alice or Bob has any memory; they share a secret value (for HMAC), but they have not read-write slot to update. On the other hand, you also assume that Alice and Bob have clocks which are reasonably accurate (within a few minutes of each other).

If Alice and Bob have clocks but no memory, then your solution is reasonable. Your math is a bit off:

If Bob allows for a deviation of X minutes, then he will compute 2X+1 values, not just X.
Replay attacks are possible for up to 2X minutes or so, if Alice's clock is too early by X minutes.

If Bob has some transient memory (RAM...) then he can furthermore protect himself against replay attacks by remembering the messages received in the last 2X minutes: that way, Bob can detect replay of messages which are not too old (and old messages would be rejected because of their age).

If Alice and Bob have permanent read-write memory, then they can use a counter instead of a clock. This can make hardware implementation much easier (clocks need a constant energy supply, counters do not).

Your main mistake, though, is that you are trying to define your own protocol. This is, generally speaking, not a good idea. Instead, you should rely on existing, peer-reviewed protocols. Therefore, you want to use HOTP (for the counter-based solution) or TOTP (which internally reuses the HOTP mechanics). You are warmly encouraged to read through their respective RFC (RFC 4226 and 6238, respectively), which are nicely written.

(You were not far, though. Your proposal is quite close to TOTP. But cryptography is subtle, so using existing standards is always better.)


How is Facebook's new delegated recovery more secure than a traditional recovery system

Pros:

The recovery provider might have two/multi factor authentication.

-> might be more secure than your email provider

When your email account is hacked and an attacker takes over your account at an account provider you can recover it.

Cons

You have to trust your recovery provider
If someone gets access to your account at the recovery provider the person is also able to get access to your other accounts

Summary

You should only use delegated recovery when the following conditions are met:

you trust the recovery provider
the recovery provider provides more secure authentication, e.g. two factor authentication

Possible solution for better security

An account provider may provide a recovery system where you have to access multiple recovery providers to proof your identity, e.g. facebook and stackoverflow.


Is it possible to increase the cost of BCrypt or PBKDF2 when its already calculated and without the original password?

PBKDF2 and Bcrypt do not support increasing the cost, starting from the output at a given iteration count, without knowledge of the password. There is no intrinsic reason for that; a password hashing process could allow for such offline stretching while still be "good". But these algorithms happen not to allow it.

What can be done is the following: a normal bcrypt or PBKDF2 output includes the salt s, the iteration count i, and the hash output v. In bcrypt implementations, the three values are often encoded into printable characters (with a Base64-like encoding); see for instance this answer. Assuming you have s and v, you can store the following:

the salt s;
an iteration count i;
an extra iteration count j;
the value h(h(h(...h(h(v))...))) which is the result of hashing v repeatedly, with a secure hash function h, done j times.

For password verification, you have to recompute the bcrypt/PBKDF2 from the given password (using s and i), and then hash the resulting value j times, to see if it matches the stored value.

This is mostly secure, if you use a strong hash function for h, like SHA-256. It can be shown that the repeated hashing reduces the space of possible values, but should reach an inner "cycle" of size roughly sqrt(N) if the hash output values are in a space of size N; moreover, if that cycle is small enough to be explored exhaustively, then a collision on the hash function h can be computed (see this page for a nice diagram). Thus, if h is collision-resistant (like SHA-256), then the scheme above is safe.

The important point is that you can increase j afterwards, in an offline way. However, note that this kind of stretching relies on the computing cost involved in doing many extra hash function computations. Unfortunately, usual hash functions like SHA-256 map really well on what GPU can do; thus, the advantage obtained that way over the attacker might not be as great as initially wished for. In other words, using the stretching described above voids any advantage of bcrypt over PBKDF2 (see this answer for a discussion on this subject). You could apply it as a temporary measure, until the said user comes back, so that the bcrypt step could be done again with a higher iteration count (i).

Moreover, the scheme I describe above is homemade crypto, and that's bad. I can get away with it because I am totally awesome, but this cannot be promoted on a general basis.


Is it secure to overwrite unencrypted files with encrypted ones?

I infer two things from this question, so I will explain the first. You have a text file (we'll name it test.txt) My first interpretation:

Open text file
Select all content
Overwrite content with encrypted content
Save file

If you never copied unencrypted data, the data would be cached so it would be retrievable. If you're using Windows, depending on the version, you could do it with Volume Shadow Copy

Second interpretation. You have a file called test.txt and a file called encrypted-test.txt and you are copying/moving encrypted-test.txt to test.txt. In this instance the data is gone. In order to understand why, you will need to learn forensics, or read a briefer on it.

The tl;dr version: Deleted data isn't really deleted. Bits are re-assigned, and marked as available. While data is still visible on your disk, it is invisible to the naked eye. Until your disk reaches full circle to overwrite those segments, it can be retrieved. If data is OVERWRITTEN it is usually gone, but can be (possible) recovered. You may be able to retrieve fragments of the content of the overwritten file, but the entire data... It's gone.

  When a sector is overwritten it is exactly that.  The previous data is
  all overwritten and lost.  With earlier disk drives, maybe pre year
  2000, it was occasionally possible, with government budgets to recover
  data from some overwritten sectors and this has caused a lot of ‘folk
  law’ about such recovery.  With a modern, very high density drive
  drive this is now impossible, and any software package that say it is
  possible is ‘being creative’.  The only way to recover an overwritten
  file is by finding another copy - often called a backup. (source)

To answer your question: "Is it secure to overwrite files..." It is an uncommon way, but will work. If the goal is to make a file irretrievable, here is a horrible method to do so. Make an mp3, rename the mp3 to test.txt then overwrite it two or three times. Many forensics tools will attempt to fix the headers and trailers for file carving (identification). So mp3 headers become txt file headers. The entire document is now gibberish.


How to get IP address of a virtual box machine from hostmachine?

As Steffen Ullrich said on comments, there is not so much related to security here. Ok, you are trying to do a CTF... but that's all. Anyway before the probably migration of the question I'll try to give you some hints.

First you must determine if your virtual machine is running in NAT mode or in bridged mode. You can check it under configuration-networking options for that machine on Virtualbox.

If is in bridged mode, the virtual machine is going to be on same network as your host machine. Probably it will take an ip from DHCP if you have one configured which is the standard. If bridged is your case, suppose that your home network range is 192.168.0.0/24. Use nmap to scan your network in order to find your vm. A command like this usually is enough (a standard connect scan generating a lot of noise):

nmap -sT 192.168.0.0/24

Remember to change your network range on command if is different.

If your vm is in NAT mode. There will be a different network range between your host machine and your vm. Usually, the default network range for this on Virtualbox is 10.0.2.0/24 (your host usually is 10.0.2.1 and the first vm should be 10.0.2.15 if everything is normal).

Hope it helps.


Is Telegram bot phone number sharing feature a sufficient way to authenticate a user?

OK, it can seem insecure at first sight, but, if bot will perform user check right, it'll give 100% confidence in authenticity of user's phone number. And it's authenticity is proved by Telegram authentication mechanism (which is SMS verifcation).

As ximaera commented:

  Be careful to check whether the id of the user you're communicating with matches user_id value of the contact you've received

Any telegram app sending any contact as object with first name, last name and phone number properties. There's no other ways that Telegram API allowing to do it.
And the bot receiving this object with user_id appended by telegram server. This additional property equals to chat_id of user with this phone number.
So, it appears that it's enough to compare user_id from contact with chat_id of user, who sent this contact.

K.B. said:

  Phone numbers are pretty easily spoofed

Our webapp uses SMS-verification of phone-number during registration. The same is done by Telegram. Hence, our authentication mechanism isn't safer that Telegram's.

  If the user's device is stolen/lost/otherwise compromised, the token can be revoked

If the phone is stolen/lost, and not protected with PIN/fingerprint/other, the new phone owner will have all the resources to regain control on any user's account.

Of cource, security measures are not superfluous, especially when extending the zone of trust to a third-party service. But, I think that Telegram's security way ahead of ordinary application's security, so, once integrated, it can be further used even as authorization mechanism, instead of SMS verification codes.


I'll do my best to answer your points, as each situation is different.

1 - If you're using an SSL VPN solution (which is probably the case), the only way they would be able to decrypt your traffic is if they got a hold of the VPN servers private key (this is the way SSL/TLS works). Even if your traffic is captured, they wouldn't be able to decrypt it without the private key, unless a very weak cipher is being used (i'm leaving out the possibility of a MITM attack).

2 - I personally use iVPN on a daily basis with a PPTP VPN setup. I like it, very good for the price you pay and extremely easy to setup. I have no experience with Mullvad.

3 - This isn't very clear - every provider is different. You might not even need a 3rd party client depending on the solution you go for. I use my Mac VPN settings to connect to my iVPN server from my MacBook, and the iPhone VPN settings from my phone. Both support VPN connections out of the box. Windows does too.

4 - It's always good to be weary about open source solutions, but generally, if you download a client from a reputable provider and you're paying for the service, they are responsible for making sure their software does not contain malicious code - even if they are building their solution from Open source software. Exploits can still be (and will be) discovered, not much that can be done to prevent that - but they should provide patches to fix any exploits which are discovered.

There is a lot of every good documentation on how VPNs work, and their purpose. There's a lot of information here:

http://computer.howstuffworks.com/vpn.htm

Hope this helps.