Who is responsible for revoking a certificate?

The answer by user2320464 is good, but I'd like to expand more.

Summary: The certificate holder generally does not manage their own revocation information, because the whole point of revocation is to announce that holder of this certificate is not trustworthy. The rightful owner of the cert needs to be able to declare the cert Revoked, but in a way that an attacker who also has the private key can't "undo" the revocation. If the owner of the cert themself are no longer trustworthy, you need a way to revoke the cert even against their will.

The best solution we've found is for a 3rd party to track the revocation info, usually the CA that issued the cert. They maintain blacklists, and can also respond to online requests for "is cert #28277392 revoked?".

Why revocation is ugly

Revocation really is the ugly duckling in the certificate world; we haven't yet found an elegant way to handle it. The reason it's hard is that there are seemingly conflicting requirements:

When a server hands their cert to a client, the client should be able to tell if the cert is revoked.
The server shouldn't be responsible for generating or passing on revocation information for its own cert. That's like asking the dog to go check if the cookies are still there, and not lie about it.
So the CA needs to be dynamically generating revocation info for each cert. (or at least tracking it and publishing the black list hourly or daily).
One of the beauties of certificates is that they contain all the data to validate the signature, which you can do offline and very fast.
But revocation has to be real-time, you can't just put it in the initial cert and forget about it, because you never know at what point it will be revoked.
If the client has to contact the CA directly for every cert validation then it's impossible to validate a cert offline, and you add network lag.

There are two main revocation mechanisms in use today: CRL and OCSP (see below), but neither are really elegant solutions.

Why certificates get revoked

Your comment

  Does the client/server "mark" it as revoked?

leads me to believe that you don't fully understand why a certificate would get revoked. There are typically three broad reasons for revoking a cert:

The rightful owner of the cert is abusing it. Typically this would be a sub-CA who is issuing certificates they shouldn't. Their cert gets revoked to tell the world not to trust them anymore.
The server is decommissioned, or the cert is no longer needed for whatever reason.
Key compromise of the private key corresponding to the certificate. We can no longer trust anything signed by, or encrypted for this cert because we no longer know if we're talking to the rightful owner or the hacker.

In case 2) the owner of the cert could flag their own cert for revocation in the way you're suggesting, but in the other two cases the attacker could just use an older version of the cert from before it was revoked. So revocation really needs to be handled by a 3rd party, out of the control of the cert holder. Usually it's done by the CA that issued the certs.

To revoke a cert, you typically contact the CA, prove you are who you say you are, and request them to revoke the cert. I think it depends from CA to CA what level of proof they need before they will revoke a cert for you - this is to prevent an attacker from requesting a cert be revoked as a denial-of-service. For end-user certs like a server cert, often revocation is automated and signing the network message with the cert's private key is good enough (ie a cert can revoke itself). For revoking high-value certs like a sub-CA, there is a lot of IT work and cleanup to be done, end-user certs to be migrated and re-issued, fines to be paid, etc, so a revocation will be a major incident involving many people from both companies.

How certificates get revoked

  is there a blacklist of certificates maintained somewhere that contains all the revoked certificates?

Yes. The simplest mechanism is called a Certificate Revocation List (CRL) which is exactly what you expect: a list of the serial numbers of all revoked certs. Each CA is responsible for tracking the revocation status of all certs that it has issued and publishing a new CRL hourly or daily. The CRL is signed by the CA key, so it is tamper-proof. It's just a .crl file that you can download, pass around, wtv. This can be used semi-offline, as long as you connect and refresh it once every 24 hours, you can use it offline (but of course, you have no way to know if you're talking to a compromised cert until your next CRL refresh).

The more complex "cloud-friendly" mechanism is called Online Certificate Status Protocol (OCSP). The client opens a connection directly to the CA and asks

Client: "Hey, I've got cert #9388038829188 that you issued, is it still good?"

CA: "Yup, it's still good".

This solves the delay problem with CRLs, but requires the client to be online, and adds network lag to the crypto process.

In 2011 a system called OCSP Stapling was introduced that allows the sever to pre-fetch the OCSP response from the CA, say once every 5 minutes, and bundle it with the cert when handing it to the client. This, among other things, speeds up the client's crypto to validate the certificate because it has a local copy of everything it needs, no new network connections needed. This is considered an elegant solution for TLS (ie https, ftps, ssh, vpn, etc) where you are opening a connection to a server that has internet access, but it does not solve revocation for non-TLS uses of certificates, like logging into Windows with a PKI smartcard, launching code-signed software (like any mobile app), opening a signed PDF document, etc which I would like to still work even if I'm not connected to the internet.

How it gets passed to the end user

  is there a field on the certificate that tells that it is revoked?

Yes, in an X.509 certificate (like SSL) the address where you can find the CRL goes in the CRL Distribution Point field, and the OCSP address goes in the Authority Information Access field. For example, the cert for *.stackexchange.com that is protecting this page contains:

[1]CRL Distribution Point
     Distribution Point Name:
          Full Name:
               URL=http://crl3.digicert.com/sha2-ha-server-g5.crl
[2]CRL Distribution Point
     Distribution Point Name:
          Full Name:
               URL=http://crl4.digicert.com/sha2-ha-server-g5.crl

[1]Authority Info Access
     Access Method=On-line Certificate Status Protocol (1.3.6.1.5.5.7.48.1)
     Alternative Name:
          URL=http://ocsp.digicert.com
          URL=http://cacerts.digicert.com/DigiCertSHA2HighAssuranceServerCA.crt


Alternative to Qubes OS network domain for a server

"That allows to prevent the use of a potential bug in the network
  driver."

In the host ...
The network VM is now the vulnerable part and certainly one of the more important VM's.

  "How can I reproduce the same configuration ? I thought about using
  Xen with a virtual network, but I would like to know if somebody
  already made it."

Depends on the hypervisor and OS. You are looking for something like PCI passthrough, DDA, SR-IOV


Pick a softer target.

Facebook is on the Chromium HSTS preload list

Twitter is on the Chromium HSTS preload list

Update 1
So:
Pick a target that doesn't use HSTS and/or pick a browser that doesn't care about HSTS.


Is there a "classic" information security textbook?

I would actually say that there is one, Ross Anderson's security engineering is it, and it's free:
http://www.cl.cam.ac.uk/~rja14/book.html
https://www.schneier.com/blog/archives/2013/03/ross_andersons_1.html

I also agree with executifs's comment - the books he mentions are the books regarded as core to those disciplines.

Ross Anderson's book has the correct title though for what it is - it gives an overview of what's involved in many areas down to a satisfying level of detail.


Is it safe to use this embedded ftp server?

I'll try to answer the questions with the following explanation.

Describing the lack of development only is not a risk. But that is matter of opinion as well. But, the dependencies of your library (for example Java, and others) might be. This means that for example the library might be (known) bug free, and stable indeed. But the underlying Java version might become the problem, introducing known vulnerabilities.

In order to asses that, you should audit the library including dependencies to say something useful about it.

Risk assessment

Also you should take in consideration the likelihood. Is this only accessible behind a Virtual Private Network (VPN) or behind a SSH tunnel with Private Keys in place, or both? Or is it open to the whole world? Then also consider the possible impact. Are there two users on the platform or twenty thousand? Can they open some media files only? Or highly confidential and classified information?


Each block of the output of PBKDF2 is derived independently of all the other blocks.  Because of this, computing a large output on a massively parallel system (such as a GPU) is very efficient.  Further, if you only take certain bytes of the output and discard the rest, an attacker only needs to compute the blocks containing those bytes.


htaccess - protect php file execution in specific directory

Have you tried using "'s?

<Directory "^public_html/product/uploads">
<Files "^(*.php|*.phps)">
    order deny,allow
    deny from all
</Files>
</Directory>

This would deny users from accessing PHP files.
Alternatively, you can disable the PHP engine for this directory, allow the files to be read. Check out the related question Disable PHP in directory (including all sub-directories) with .htaccess


What is the most secure way to store cross subdomain cookies

From RFC 6265:

5.1.3.  Domain Matching

 A string domain-matches a given domain string if at least one of the
   following conditions hold:

   o  The domain string and the string are identical.  (Note that both
      the domain string and the string will have been canonicalized to
      lower case at this point.)

   o  All of the following conditions hold:

      *  The domain string is a suffix of the string.

      *  The last character of the string that is not included in the
         domain string is a %x2E (".") character.

      *  The string is a host name (i.e., not an IP address).

That is, if the domain name in your cookie's domain parameter doesn't start with a period, then it will not let subdomains read that cookie.  If it does start with the period, then all subdomains will have full access to that cookie's value.

For example:

Set-Cookie: lang=en-US; Path=/; Domain=example.com

Can only be read by example.com.

Set-Cookie: lang=en-US; Path=/; Domain=.example.com

Can be read by example.com and any subdomain, including foo.example.com, baz.bar.foo.example.com, and baz.example.com.

Set-Cookie: lang=en-US; Path=/; Domain=foo.example.com

Can only be read by foo.example.com.

Set-Cookie: lang=en-US; Path=/; Domain=.foo.example.com

Can be read by foo.example.com and any subdomain, including baz.bar.foo.example.com, but not example.com or baz.example.com.

If you want to share cookies across subdomains, but leave out other subdomains, you should explicitly state which subdomains you want to read them, setting a new cookie for each, rather than using wildcards.


Do I need to set maximum characters length for password using bcrypt?

Well Dmitry is right when he says 72 characters is good. If the characters are random enough. (1.78 bits per character).

You can use the approach described (security warning that password is "too long"). Or simply limit password length (with security warning).

If you expect your users to enter more than 72 characters, you could as well use SHA-512 to prehash the password, so you'd feed the hash into the bcrypt (as password) and not the actual password. There are no security issues with this approach. However it is non-standard, so if you do need to provide interopability with other applications (not yours) you can't use it.


How to figure out that someone is ARP spoofing me and what to do against it?

The detect ARP spoofing, you typically capture packets and look for gratuitous ARP advertisements. That way you can also see what device is doing the spoofing.

To defend, you need to configure your device/network with static ARP assignments.


How does the website "whatsmyrouterip.com" detect the LAN router IPaddress and the LAN device IP address as well as the WAN gateway router IP address?

The site just tries some typical IP addresses for routers to see if something is there. Typically the router is either at the IP address xx.xx.xx.1 or xx.xx.xx.254 where the IP address is from the range of private IP addresses. It tries these and some other addresses in the range of the local network(s). Which local networks these are seem to be determined using WebRTC (thanks for schroeder@ to pointing this out - see his comment for more information).

This behavior can be traced if using the developer tools in the browser and looking at the requests taken:

If there is some kind of response when accessing HTTP on these IP addresses it is assumed that this is the admin interface of the router. It cannot actually read the content to check if this is a router but just checks based on the timeout of the request if it was successful or not. Thus, if there is some non-router at such IP it will guess wrong (as it does on my system) and if the routers admin interface is on some address outside the local network it will fail to find it this way. But it will work for the typical setups users have at home.


How to configure proxy settings of cellular internet for burp

The cellular issue when testing mobile apps does make them a little tricky to test. Some app's are aware of when they are communicating via the telecommunication provider directly and in some cases will behave differently when connected. some very old app's had a horrible pattern of sending data securely when sending data via 802.11 (using IPv4) but would send data over the cellular network (frequently via IPv6) in cleartext.

I've also seen issues where the app developer considered the telecommunications network to be encrypted when it simply wasn't.

Additionally apps created by the telecommunications providers frequently do this.

If you trust the app to behave normally you can use the Android Debug Bridge:

http://developer.android.com/tools/help/adb.html

see

http://www.mcafee.com/us/resources/white-papers/foundstone/wp-pen-testing-android-apps.pdf

However if you don't trust the device to behave properly, or you're more paranoid, you can setup a cell phone signal booster running linux and put it and the phone/device into a faraday cage style evidence bag (faraday bag) or box then use IPTables to redirect all traffic out of the bag via a physical ethernet cable to a system running your proxy. Some faraday bags and signal boosters are very inexpensive.

The primary advantage of this is you capture the data going over the telecom network side and not just what would be sent via 802.11. Likewise similar configurations with different antennas/equipment could be used to test NFC, bluetooth or any other wireless protocols the device may support.

@Lucas Kauffman just reminded me to mention that all RF equipment including things like cell phone boosters may be subject to your local laws and depending on where you are they may be illegal.


If multiple users on the same website all use the same password, is their password hash the same?

It depends on whether or not they add individual salts or if they use a common salt (or no salt at all).

If they use individual salts, then they'll be different; otherwise, they'll [likely] be the same.


Can read receipt on sign up and password reset emails be used to enhance security?

The only way I can think of this improving security is that any links/tokens get revoked sooner.

Example: with an password reset email the token may be valid for 1 hour, if a read receipt is received after 6 minutes it would be reasonable for that token to only be valid for another 5 minutes. This reduces the attack window from 1 hour to 11 minutes.


Are passwords stored in the cookie? encrypted?

Usually, the password isn't stored in the cookie.  You login to example.com with your username and password, these are verified to belong to you (typically by hashing your password and checking the hash of your password matches with the hash for a user with that username), and the server issues you a long random number token as a secret identifier for you.

Say they choose 24 random characters from 62 characters (26 uppercase letters, 26 lowercase letters, 10 numbers).  They store this identifier in their database as being valid and associated with you.  Every time you make a request while logged in - you send the cookie to your website.  Every time there is a request sent in with this identifier, they look up if its associated with a valid logged-in user, and if it is they give the information about that user.

There are 6224 ~ 1043 ~ 2142 possibilities.  If your website has a billion (10^9) signed in users at any moment who were issued tokens, you'd have to try roughly 10^37 possibilities until you'd be lucky enough to randomly guess one.  (If each try takes 1 nanosecond, it would take you about 1011 billion years before you were lucky to guess a valid token).

Your session cookie is typically only valid for a certain amount of time, which will also be stored in the server side database.

There are other variations on this theme, e.g., using HMAC (hash message authentication codes) with a stored timestamp based on a server-side secret.  That is when you login the server gives you a timestamp as well as a strong hash of that timestamp and your username that is combined with a server side secret.   That is you the server calculates h=HMAC(secret + timestamp + username) when you login, gives you back the calculated h -- and then you send (h, username, and timestamp) as your login information.  (And the server takes your username and timestamp, recalculates h and compares it to the h you gave, and makes sure the timestamp is still valid and not very old).

Now I am not particularly familiar with the particulars of how stackexchange does it (e.g., what the t=...&s=.... part of the .security.stackexchange.com), but its probably a variation on this scheme.  That is it does not encrypt your username or password in a recoverable way -- it either is stored in a database or is based on one-way hash function that relies on a server-side secret.


Is it must for a packet sniffer to enable promiscuous mode?Can packets
  be sniffed without the NIC being in promiscuous mode?

No it is not a must and sniffing can be done in non-promiscuous too.

  Also when in promiscuous mode the NIC accepts all packets which are
  not addressed to it's MAC address.Does it also mean that it responds
  to all packets(it receives) that require a response? E.g : will it
  respond to all ARP requests(broadcast packets) not meant for it's
  MAC?Will it respond to all ICMP echo messages?

Sniffing can be done in non-promiscuous mode too. But it really depends what traffic you want to sniff. If you want to sniff the traffic that is not intended to your NIC address then use promiscuous mode. On other hand in non-promiscuous mode, your NIC will drop/ignore the packet that it not intended to its address. Your machine will by default respond to all the braodcasts and multicasts(if your machine is in the same multicast group). By the way broadcast frames in general has destination MAC address of FF:FF:FF:FF:FF:FF. Thats the reason why every device will receive that packet.

In case of ARP, only that particular machine will respond who has that particular IP address for which the ARP query is being made! If I make an ARP probe for 10.0.0.1, then my ARP probe/packet will contain this information and the ARP probe will be broadcasted. So every machine on the same broadcast domain receives the ARP probe/packet but the machine with the 10.0.0.1 IP will only reply to this ARP probe. Others will drop it.

For TCP/IP I would recommend TCP/IP Illustrated, Volume 1: The Protocols, 2nd Edition By Kevin R. Fall, W. Richard Stevens I had it in my bachelors and it is a great book and will clear all the concepts. I would like to recommend it.


This cannot reliably be done. There is no way to prove without a doubt that the site operator is telling the truth or not forging some value.
Even if you were able to prove that the source code is identical to that which is published, that doesn't really say much since 3rd-party or system libraries could be tampered with without affecting the application source.


Challenge: How to find the secret key in homebrew MAC/keyed hash: sha1(key + cookie)?

and to accomplish the goal you have to find the key value.

Do you really need to recover the key to accomplish the goal?

The scheme you have described is vulnerable to the classic length extension attack where a hash function is misused as a message authentication code. The attack is described very well in the Wikepedia article so I shall avoid replicating the example here.

With the length extension attack, you can generate a valid signature without knowing the actual key value, which is presumably enough to solve the challenge.


Why do Symantec not believe their customers will be affected by Google distrusting this root certificate?

From Symantec itself you get the following description at https://www.symantec.com/page.jsp?id=roots about the usage of VeriSign Class 3 Public Primary CA:

  This root CA is the root used for Secure Site Pro Certificates, Premium SSL Certificates and Code Signing Certificates. Effective December 1, 2015, Symantec has discontinued the use of the VeriSign G1 root for issuance of public SSL certificates. This root CA will be used to issue non-public SSL certificates. Browsers/root store operators are encouraged to remove/untrust this root from their root stores.

This suggests to me that this CA is not (or no longer?) intended for any kind of public certificates on the internet and thus removing it from the browsers will not cause any problems. In fact, they even suggest this.


Is there any sort of vulnerability in this case? More specifically, is it possible to get y1 from y2 and vise versa? Is there anything else I need to look out for?

You can construct a pair of secure hash functions where y1 can be computed from y2 and vise versa:

function#1: SHA-256
function#2: SHA-256 with the first two bits swapped

Both functions are obviously different and both are secure in that you cannot get the input from the output nor do collision attacks. But obviously you can compute the result from function#1 if you know the result from function#2 and vise versa.

  Does security in this specific case come down to the "correct" selection of the hash function pairs? Or does it not matter?

I think with hash functions based on completely different ideas the chances are high that you will not find a dependency between the outputs. But on the other hand lots of seemingly unrelated problems in math are found to be related at the end. Thus I think you would need to prove the independence for each pair of hash algorithms.

  Now, replace "hash" in this question with "key derivation function". Does it make any difference?

You can create a KDF with dependent outputs the same way I've created the two dependent hash functions. Also KDF are often based on hash functions so I would suggest that one can use the same argumentation I've used for hashes.


Encryption strength veracrypt vs keepass?

Both products uses strong encryption, but there are a few fundamental differences in their designs.

Assuming that there's no big in the implementation, then Keepass has a slight advantage in its cipher mode, as it uses CBC while full disk encryption like Veracrypt used XTS/XEX to support random access.

Cipher mode like CBC that's used in Keepass means that it has to rewrite the entire encrypted database from scratch on every writes. CBC supports random reads but not random writes. For the use case of password managers, where the file size typically only range in the megabytes, this is fine, but a full disk encryption has to work with files in the size of gigabytes, terabytes, or even petabytes that is constantly updated.

For those reasons, XTS/XEX is used in full disk encryption to support fast random writes, it is the state of the art cipher mode for full disk encryption and is not known to be broken, but because it has to support random writes, it has a few weaknesses/tradeoffs and leakages that cipher modes that doesn't need to support random writes don't have. You can read further about the challenges with full disk encryption in "You Don't Want XTS".


End user composes email linking to external domain: Best practices?

There is no answer to the "why don't we" kind of questions because they are based on false premises: you're assuming that because you don't do it, nobody does. Specifically, there are plenty of mail security tools that will let you do things as simple as filtering mail based on regular expressions (which is enough to perform the filtering you're requesting).

Now, there are additional elements that you're not taking into account. For instance, an organization might use technologies like DKIM, SPF or even S/MIME to validate the authenticity of messages and help the end user assess the validity of messages. Since there is simply no way to prevent incoming mail from being gross forgeries ("hi, I'm Brenda from accounting. This is my private mail. Could you please...") the most efficient step for protecting your org is to teach users to look for positive identification markers (like the source domain name and, if possible, the digital signature of incoming messages).


How long would it take to generate a file to match a hash?


How can I find the origin of an IP address for a relayed IP?

Short answer:  Without either a trusted place on the internet (access to an Internet Exchange [IX]), ability to subpoena ISPs for logs/records, or some other intelligence (e.g. this IP also has posted to wikipedia with information that could lead to their identity), you don't.

When one uses a relay or a VPN to obfuscate their IP, there is no way the other end can tell what the originating IP is.  All of that information is not included in the packets.  The only way to actually trace it would be to get records from the ISP of the IP they are using, and determine what other connections were active to that IP.  From there, one can begin to determine the originating IP address.

There is no such thing as "spoofing their IP" on the open internet when it comes to TCP sessions.  When one spoofs their IP, they change the packet header to indicate the packet has come from a different IP than their own.  However, this causes any return packets to go to the spoofed IP, and not the real IP.  IN the case of TCP traffic, which includes http, SSH and most protocols the attacker is likely to use, a TCP handshake could never occur.  This is because the spoofed IP will not respond to the TCP SYN (synchronize) statements, and thus no TCP socket will be created and no data can be sent.

In order to spoof an IP address on the open internet, one would have to use a BGP hack or do something of that sort -- prohibitively difficult attacks typically restricted to nation-state level cyber staff.

The question becomes:  Why does the IP address matter?  If there is a way for someone to steal, close that vulnerability and eliminate your exposure; so no matter where they come from they can't do anything malicious.


Sophos AV doesn't block standard ClamAV test files

Clam.exe which is used in these tests is a harmless test program similar to the innocent EICAR test virus, i.e it just prints a message. But, contrary to the also harmless EICAR this test file is not generally treated as malicious by antivirus programs and thus will not be detected. And I have no idea why ClamAV needs to have their own test program instead of the commonly used EICAR test.

Thus if Sophos detects EICAR but not the clamev.exe test program inside ZIP, mails etc you can assume that Sophos still can detect malware inside ZIP files and mails and ignore that it does not detect the ClamAV specific test program.

  According to the audit team, these are standard "dummy" test files that are just meant to be picked up by antivirus software, but are innocuous.

I would question the competence of the audit team if they make such claims. Just check with virustotal and you'll find that almost no antivirus will detect this as malware.


Linkedin spam through Skype - how to check if I am infected?

Unless Linkedin site is compromised or vulnerable to Open Redirections, XSS or CSRF you should be fine.

For better practice when opening suspicious links you can download sandbox browser that will isolate and protect your PC from infection.

http://www.sandboxie.com/


Could Google Mail or Google Drive work as a path to a company's network?

Short answer: No
Long answer... it depends on how well you secured your account (i.e. two-factor authentication, SMS/mail alerts etc.)
Google drive is a cloud service, logged in through either an app or via the web browser, unless someone completely hacks and bugs the (web)application and spikes it so it reads into your system (which requires them to also crack the security of your system/browser/phone etc.), it MAY have a way in... which will never happen, obviously.
Storing data that could be confidential in the cloud always has the risk of someone accessing the account, having two-factor (or even more advanced, 3 factor) is your best move, and should ALWAYS be enabled for security, this is the same for Google drive, OneDrive, Dropbox, name it!


There's no way to prove that unless you inspect every line of relevant source code involved. If you do have access to every line of code, then yes, you can prove to your satisfaction that you're dealing with end-to-end encryption.

However, since the code can be changed at will by Facebook, you'll have no way of knowing whether communication remains secure after your code inspection, or whether it was secure before you inspected the code.

So, unfortunately, the answer is that just like with much of the rest of our lives, you'll have to put some trust in what other people - Facebook, in this instance - tell you. You'll have to decide whether you want to invest that trust, or not.

Network monitoring

Your idea of monitoring network traffic gives you an indicator, but is by no means conclusive.

If Facebook wanted to secretly eavesdrop on your conversation, it wouldn't have to route the messenger protocol through it's own servers. The messenger could just record what you type and use a covert channel to send it to some harmless-looking server later on. The channel used to exfiltrate your messages could be fairly easy to detect (direct connection to the Facebook servers - but since it would be encrypted, you wouldn't know it was part of some other function of the messenger), something like fake DNS queries to a bogus DNS server, or any other harmless-looking form of network connection. If it was time-delayed, the chance that you'd catch it would be basically nil.

Also, even if the messenger DOES route traffic through it's own servers, this isn't a sign of wrong-doing at all. If you want messages to be held while the recipient is out of reach, and have them delivered once he comes online again, you must store them somewhere. End-to-end encryption doesn't mean the messages aren't stored somewhere; it just means that the messages can only be read by the originator and the recipient. So the messenger could do something very simple: It could encrypt every message twice: Once for the recipient, and once for Facebook. Then it would send both messages to Facebook servers, packaged to look like a single message, and you'd never know the difference.

So do they spy on you?

Note that I'm NOT saying Facebook is lying to you; in fact I believe they take end-to-end encryption seriously. If you don't believe in the inherent honesty of people or in Facebook's adherence to law, you might be more convinced by thinking about the public relations disaster that exposure would mean, and that Facebook, being locked in a fight for users with competitors, might not want to risk a significant percentage of users over something that offers them so little advantages. Because if you think about it, what would Facebook gain, exactly, from reading your messages? They already get something very valuable from your usage of Messenger: They know who you're communicating with, and they know how often, and when. This metadata might actually be more valuable that the content of the messages.


Historically, there's no computer, let alone Python code. Encryption systems have been designed and attacked and improved since many centuries before the invention of electricity. Also, only the most basic, weakest, puniest forms of encryption can be described as "unordered data".

The really must-read introduction on cryptography and decryption is this classic text. It is free (in all meanings). French speakers may want to read this remarkable translation. This simple text is quite entertaining, extremely well written, and will plant the right ideas in the reader's mind.

Afterwards, find an introductory book. I have read that one; it is not bad. Cheap pocket editions exist, and you may find it in many libraries too. Further exploration of the subject will entail doing some maths (not very complex maths, but a lot of maths). A very good resource for that advanced stage is the Handbook of Applied Cryptography, which is quite thorough, precise, full of references, and can be downloaded for free.


how does tresorit "shared links" work if files are encrypted on the server?

As can be seen in an image included into Introducing new ways of sharing in Tresorit the link for sharing a file has the syntax

 https://example.com/some-path#some-special-string

This some-special-string after the # is an anchor and it gets processed in a special way. When visiting the URL only /some-path will be send inside the request to the server example.com while the #some-special-string is kept in the browser and is accessible via Javascript by location.hash. This way some-special-string can contain the secret needed to decrypt the data and this secret will not leave the browser.

Of course, not only the encrypted data need to be downloaded from the server for decryption but also the decryption has to be done somehow. Since the browser does not know how to decrypt the data the necessary Javascript code for decryption has to be loaded from some server too. And this is the weak point of the concept - even if the server only has the encrypted data he could in theory send not only the script to decrypt the data with the in-browser secret but could also send script which sends this secret back to the server, thus making server-side decryption possible. Thus, trusting the service provider is still needed.


I live in a homeless hostel and the manager has installed a VERY invasive spyware on my computer

If it is your personal macbook you should be able to reset it to factory defaults ... here is a SE post about why wiping it is your best option.

If someone in the hostel is messing with or monitoring your connection to the internet, you could install TOR after doing your factory reset.

The mac should also have the ability to set a lock screen which isnt 100% secure, but will keep most people out of your stuff.

Once your Mac Book has been reset, TOR has been installed, and you have setup a lock screen ... you can keep an eye on /var/log/secure.log which can be used as proof of when people access your computer ... either by loging in with the keyboard or remotely via ssh.


How to block network scans with pfsense?

Two answers to this question:

You can't
Port Knocking

Services exist to be connected to. If you have a service, then you need to allow clients to connect to it, and once you do that, it is open to be 'enumerated'. You can't block someone from trying a service to see if it responds because you need that ability for clients to connect to you.

... Unless you obfuscate the service port. Port Knocking allows you to open a service port to an client IP only if the client IP performed certain actions (usually pinging certain port numbers in a particular sequence). This is not a 'secure' method, but it does effectively hide a port from unauthorized 'enumeration'. The problem with this scheme is that all clients need to know the secret knock before they are allowed access, which is not good for public services.

But even with Port Knocking, people can still try to enumerate your ports, they just might not get the true ports of the services.


Is anybody using client browser certificates?

Client side certificated just haven't had a good enough cost/benefit tradeoff.  They are very confusing to users so support costs go up.  And they are still just bits and thus "something you know" and are vulnerable to a range of software attacks on the browser, the distribution scheme, phishing etc.

Hardware token schemes (two-factor authn) are better for good authn.   Single-sign-on (SSO) schemes, potentially federated, and potentially backed by hardware tokens, solve more issues and are easier to deploy.

Managing a lot of certificates would be far more complicated for a user than the current thorny multiple-password issue, and browsers don't offer good support for selecting the right certificate.  And if a user uses a single cert for lots of sites, then there are privacy issues since use of the certificate identifies the user.

Over the decades, a lot of us have thought that the age of end-user PK-crypto was just around the corner, especially those like me enamored of the beauty of RSA.  It just turns out that the way it has evolved, the help desk and development costs and subtleties and complexities and legal entanglements of real-world PKI keep eating up the benefits.

Equipment seems more expensive than bits, but not if the bits don't do the job, or effective use of them eats up productivity.


What solution against ARP attacks in a University network?

Layer2 attacks are difficult but the fix for them has existed for some years now:  802.1X.  In a nutshell, it's asymmetric (certificate-based) authentication for all of your devices.

So even if an attacker plugs in to your network, each device is authenticated from the certificate that's been pre-applied to it.  So if an attacker on the network plugs in a rogue device but does not have a certificate, the port will never become active to allow the rogue connection to start performing any Layer2+ attacks on your University network.

The limiting factors are the need for a PKI architecture and devices that accept x509 certificates and understand (and can use) 802.1X.  If you don't already have a secure PKI architecture, this will be a rather monumental undertaking to do correctly.

Edit:  To specifically address netcut, apparently there is a free tool that will work against it:  https://arcai.com/netcut-defender/ -- I'm not making any claims on its effectiveness but if you don't want to fix the problem properly (802.1x), you're going to have to resort to something like this.


Nginx - SSL Website shows up on desktop but not mobile

You can find some more information by "tapping" NET::ERR_CERT_AUTHORITY_INVALID on the first page see this example here: https://www.youtube.com/watch?v=o8iJE7p-W4M

In short NET::ERR_CERT_AUTHORITY_INVALID indicates the certificate authority is not trusted by your Android device.

Try opening a support case with the CA (Comodo), a quick google seems this is not an uncommon issue for comodo certs.

Check https://stackoverflow.com/questions/11340298/certificate-trusted-on-pc-but-not-in-android

Also for secure SSL nginx configuration refer to: https://wiki.mozilla.org/Security/Server_Side_TLS


An empty password field means the root account can be accessed without any password.

An * or ! means the account don't have a password and no password will access the account. An x means the password is on /etc/shadow.


I have a process called “watchbog” that is completely hogging my CPU and I don't know what it is

How can I get rid of the "watchbog" process?

One of the great things about Linux is that you can just redeploy it free. I highly suggest you just wipe your OS and re-install. Trouble shooting the virus is almost always an exercise in futility in my experience. So backing up files and doing a re-install is good ROI.

If you really want to get rid of the process without reinstall, start with a "locate" for it. It's running as ./ so it's most likely local somewhere on the file system. Chances are it's got a sister process that will re-install it if you delete it, but I'd start by hunting down the location of ./watchbog and then seeing if it's a binary or script and go from there.


Short answer: you cannot.
Long answer: You want DRM and DRM may or may not work, depending on the adversary.
If a third party have access to the computer where your software is installed, they can disassemble/decompile your software and learn how it works. They can install an intercepting proxy on the computer and analyse all network traffic.
Online game companies have an entire team working on this problem, and there are always someone writing code to cheat on online games.
You can obfuscate your code, write a highly convoluted protocol, employ anti-debugging techniques, all to make more difficult to someone to analyse your software, but you have no way to ensure that only your software can access the API.
And the bad thing about DRM is that as soon as one user broke it, it's broken for everyone because it only takes that user to share a bypass online and everyone else can do the same bypass.


Given that one packet in the log snippet above, your system is not "pinging" random IPs on the internet. "Pinging" refers to ICMP type 8, an echo request. Looking closer at the packet:

PROTO=ICMP TYPE=3 CODE=13

Type 3 is Destination Unreachable (RFC792), and code 13 is Communication administratively prohibited (RFC1812). So this means your server is not reaching out to remote hosts, but rather is sending these ICMP messages in response to some traffic that is reaching it, which it appears to be refusing to forward. Without seeing the traffic that prompted these control messages, it is difficult to know exactly what is going on. I suggest that you look for anomalous traffic with matching addresses that immediately precedes these ICMP messages.


There are two separate aspects of the configuration here - the connection-level security, and the authentication-level security.  In practice, since connection-level (TLS) protects both, it is common for authentication-level security to be low ("Normal Password").  As long as you're using TLS (SMTP/POP/IMAP either over SSL/TLS or STARTTLS), you're fine.

Why?

Way back, before SSL/TLS/STARTTLS became common, the credentials were the only part of the connection people cared about protecting.  As you say, email may be transmitted unencrypted as soon as it leaves your server - so people were not deeply concerned about the potential for that being read.  However, they were concerned about their credentials.  And those credentials used to pass over an unencrypted SMTP/POP/IMAP link.

For that reason, a number of protocols specially designed to encrypt the credentials were devised.  Digest-MD5, GSSAPI, and OAUTH were all more secure SMTP AUTH methods which could be used over an unencrypted connection.  The more common types PLAIN and LOGIN, which do not encrypt credentials, would leave the password vulnerable if there were no connection-level encryption.

But then the world started encrypting the connection.  SMTP, POP and IMAP clients and servers added support for SSL/TLS or STARTTLS to protect the entire connection.  Once they became common, there was little motivation to use the more complex protected SMTP AUTH methods, because the TLS would provide all the necessary protection.  That's why your ISP is comfortable only offering "Normal Password" (which is PLAIN and/or LOGIN) - they know the TLS layer protects you.

(In fact, some stronger methods weaken security, by requiring that the server store a plaintext or reversibly encrypted copy of each user's password, rather than a one-way hash of it.  To quote Wikipedia on Digest Authentication), "Some servers require passwords to be stored using reversible encryption. However, it is possible to instead store the digested value of the username, realm, and password."  The footnote link for that latter statement goes to RFC 2617 which goes into more detail about the security trade-offs of Digest Authentication...  I've considered implementing Digest Authentication with Postfix, Dovecot, Courier, and Cyrus over the years; each time I decided I didn't like the trade-off.)


Does FCGId use environment variables? (Or is it a possible attack vector for CVE-2014-6271/7169?)

mod_fcgi itself is not vulnerable: it talks to Apache through interprocess communication rather than the environment variables of traditional CGI.  Any CGI scripts run through mod_fcgi can still be vulnerable if 1) they can be coerced into setting environment variables and 2) invoke bash (say, through a system() call or backtick interpolation).


Cuckoo Sandbox - Unable to enable internet access via hostonly & iptables

The iptables should really work.

Some more ideas:

You should check if the guest is really configured to use 192.168.56.1 as a gateway.
You should check your overall forwarding settings in the kernel to see whether it is not disabled for your vboxnet0 interface or overall:

$ sysctl -a |grep -e '\.forwarding'


What is the best way to run MitM attack on my wireless network?

If the clients were given IPs via DHCP, you could perform some kind of ARP poisoning attack.  Essentially, when a computer broadcasts to determine what MAC the router IP has, you respond with your MAC before the router can respond with its MAC.

Another option is to masquerade as an access point and trick the clients into connecting to your fake access point.  Airbase-ng is good for this type of attack.

There really isn't a way to change a setting on the router that will make clients think you are the gateway.  Also, the DNS idea, while it would work for connections using domains, it would not catch IP traffic where the IP was not discovered via DNS.


How to generate a unique and uncopyable VPN certificate/key for a specific client hardware device?

You can generate a virtual smart card on a Trusted Platform Module (TPM). A TPM is like a Hardware Security Module (HSM), except that a TPM is physically attached to a computer's motherboard and thus isn't portable.

Lots of motherboards have TPMs on them, it's just that a lot of people don't know it and therefore don't often use their TPM.  The main advantage of a TPM is probably its lower cost, relative to HSMs.  A TPM is even more affordable than smart cards, which have to be provisioned to every user and replaced whenever lost.  Another advantage of a TPM, relative to smart cards, is that its non-portability makes it unlikely to be misplaced.

About VSC's:  A Virtual Smart Card (VSC) lives on the TPM and stores the private key of a certificate.  The VSC is capable of being protected by a PIN, and the PIN can be set to a minimum level of complexity depending on how you created the VSC.

Here are some instructions to get you started (note: Windows is required):

Check to see if your TPM is active:

Click on the Windows icon, then type the following command, right-click on the icon and execute it as an administrator:

tpm.msc

Look at the value for Status.  The TPM is active if it says "The TPM is ready for use."
If the TPM is not active, you should look for it in your BIOS and enable it if it exists.
If the TPM does not exist on your system then stop here, as subsequent steps do not apply.

How to Create a Virtual Smart Card on the TPM:

Screencast video here: https://youtu.be/MSw59AKvwSo
You will need the following pieces of information before creating your Virtual Smart Card:

Name:  The name of the Virtual Smart Card, to distinguish it from any others on the same TPM (there can be up to 10).
PIN:  A password.  The password must conform to these complexity rules:

At least 10 characters
Mix of uppercase and lowercase
Must include special characters

AdminKey:  This is like a password, except that the AdminKey must be in hex format, and the number of characters in the hex format must be 48.  This equates to 24 plain text characters.  A text-to-hex conversion utility may be useful .

Example of a hex key converted from plain text into Hex:

Plain text (24 characters):
abcdefghijklmnopqrstuvwx
Hex (48 characters with spaces omitted):
6162636465666768696a6b6c6d6e6f707172737475767778

Choose your own 24-character admin key (DON'T use the example above), convert that 24-characters from plain text into a 48-character hex value, then keep your 48-character hex value ready for the following steps.

PUK:  A PIN unlock key, i.e. another password.  The PUK is needed whenever it is necessary to release a lock caused by inputting an incorrect password too many times.

Open a command line terminal in administrator mode.
Edit the following command, replacing "MyVSCName" with the name you chose above for the virtual smart card.  Then copy and paste the edited command into the terminal:

tpmvscmgr.exe create /name "MyVSCName" /pin PROMPT /pinpolicy minlen 10 uppercase REQUIRED lowercase REQUIRED digits REQUIRED specialchars REQUIRED /AdminKey PROMPT /puk PROMPT /attestation AIK_AND_CERT /generate
You will see a series of questions asking for your PIN, your admin key, and your PUK.  Paste in the corresponding values that you have prepared above.
Your Virtual Smart Card should now exist on the TPM.  You can verify its existence by listing all Virtual Smart Cards in the TPM, using the following command:

wmic path win32_PnPEntity where "DeviceID like '%smartcardreader%'" get DeviceID,Name,Status

How to Destroy a Virtual Smart Card on the TPM:

Open a command line terminal in administrator mode.
List the Virtual Smart Cards in the TPM:

wmic path win32_PnPEntity where "DeviceID like '%smartcardreader%'" get DeviceID,Name,Status
Take note of the value under "DeviceID" for the Virtual Smart Card to be deleted.
Edit and then execute the following command, replacing "MyDeviceID" with the actual DeviceID of the virtual smart card that you want to delete:

tpmvscmgr destroy /instance "MyDeviceID"

Generate a certificate signing request that is signed by the private key within your TPM:

Open a text editor such as Notepad or Sublime Text.
Copy the following code and paste it into your text editor:

[NewRequest]
Subject = "CN=[user's e-mail address or server's domain name],O=[Organisation],L=[Locality],ST=[State],C=[Country]"
Keylength = 2048
Exportable = FALSE
UserProtected = TRUE
MachineKeySet = FALSE
ProviderName = "Microsoft Base Smart Card Crypto Provider"
ProviderType = 1
RequestType = PKCS10
KeyUsage = 0x80

For the Subject line, replace the values in brackets with your own values, to match your circumstances.  (You should omit the bracket characters themselves.)
Save the text file with a ".inf" file extension.  For example:

TPM-cert-template.inf

Open a command line terminal in administrator mode.
From the command line terminal, change the directory (cd) to where you saved the ".inf" file above.
Now generate a Certificate Signing Request (CSR).  Copy and paste the following code into the command line terminal:

certreq -new -f TPM-cert-template.inf TPM-cert.csr

You should see a pop-up dialog from Windows which asks you to select the Virtual Smart Card that will generate your certificate signing request.  Note that a TPM can store multiple Virtual Smart Cards, but in this pop-up dialog you may only see just one of them (if more than one exist).  Make sure that you expand the list before selecting a virtual smart card, and thereafter you'll see clearly to select the specific Virtual Smart Card that should generate the signing request.
After selecting the virtual smart card, you'll need to input the PIN.
If you input the correct PIN, then a new file should be generated in the same directory:

TPM-cert.csr

Prepare your server to authenticate your key pairs:

You should now have a CSR that you will need to have signed by a certificate authority.  Once the certificate authority has signed your CSR, it should send you back a certificate in either PEM or DER format.
If you don't have a certificate authority, you can create your own, but creating your own will mean that every client that uses your signed certificate will need to recognize the certificate authority that you created.  To do this, you'll need the certificate authority to send you not only the signed certificate that you were initially seeking, but also the certificate authority's own root certificate.

If you are using your own private certificate authority, then you'll need to get every server that you authenticate against to recognize your private certificate authority.  This will involve installing the root certificate of your private certificate authority on every server that you authenticate against.

Once you have the signed certificate from your certificate authority, you'll need to install the signed certificate on every server or VPN that you need to authenticate against.

Prepare your server to authenticate your user:

To get your client software to authenticate with the server or VPN where you installed your certificate, you'll now need software which can leverage the APIs that connect to your TPM.  For this there is a utility for Windows called PuTTYWinCrypt, which is a fork of the popular PuTTY program.  It enables you to connect to a server over SSH or SCP.  The source code for PuTTYWinCrypt is available on GitHub at the time of this writing.  The author of this software has also written a fork of related software often combined with PuTTYWinCrypt known as PageantWinCrypt, which runs in the background keeping the keys in memory.
Now that your server recognizes your certificate authority, you should prepare it to recognize the public key of the specific user who will be connecting.  The public key needs to be in OpenSSH format, meaning that the entire text of the key is written out on a single line.  You probably won't be able to convert your public key from PEM into OpenSSH format, because such a conversion requires that you have access to the private key.  In your case, the private key is confined to your TPM and is therefore not directly accessible.  The following steps will help you obtain your public key in OpenSSH without direct access to its corresponding private key.
Download and execute PageantWinCrypt.  This software is a patched version of the popular program Pageant, which stores keys in memory and runs in the background as an icon in the Windows system tray.  Once you double-click on the executable file, not much will be obvious except that there is now an icon for PageantWinCrypt in your system tray, indicating that PageantWinCrypt is running.  Note that the icon for PageantWinCrypt is labeled as "Pageant," not "PageantWinCrypt," so you'll need to be sure that you're specifically running PageantWinCrypt in order for this to work.
Click on the Windows icon in the lower-left corner of the screen, type the following, right click on its icon (which should appear as you type), and select "Run as administrator":

certmgr.msc

A window should pop up, showing a list of certificates with expandable folder icons.  You need to find and expand the specific folder where you installed your signed certificate.  Within that expanded folder, left-click on the subfolder called "Certificates."  Left-click on your specific certificate, to select it.  Then go to the "Action" menu item, and select "Copy" from the dropdown.  Your certificate is now in memory.  You need to import it from memory, into PageantWinCrypt.
Right-click on the icon for PageantWinCrypt in your system tray, and select "Add Certificate."  You may get a pop-up dialog saying "Select a Certificate."  Click OK.  Your key should now be in PageantWinCrypt.  You can confirm this by right-clicking again on the Pageant icon and selecting "View Keys."  There should be a line entry which corresponds to your key.  It may not be obvious but you can copy that line entry into memory simply by double-clicking on it.  Paste the copied line into a text editor, such as Notepad.
Observe the pasted text.  It should all be on a single line.  But there are two parts to this long line, and you'll need to separate the parts into two lines.  The second part begins with the following, and continues all the way until the end of the line:

cert://

In your text editor, click the mouse to just before cert:// and press Enter a few times on your keyboard.  There should now be two lines of text, with the second line beginning with cert:\\.  Note the following:

The first line is your public key in OpenSSH format.  If your server is on Linux, you'll need to add your OpenSSH-formatted public to your server's authorized_keys file.

To find the location of your authorized_keys file, connect to your Linux server via SSH and input the following command. A search will occur, and then output the path to the authorized_keys file:

sudo find / -name "authorized_keys" 2>/dev/null

Take note of the path to authorized_keys from the step above.  Now you need to edit authorized_keys and paste in your OpenSSH-formatted public key.  Execute the following command, replacing the text "[path-to-authorized-keys]" with the path in your case (omit the brackets from the example below):

sudo nano "[path-to-authorized-keys]"

The Linux-based text editor nano will now open, displaying the contents of authorized_keys.  Scroll to the bottom and add a new line, by pasting the OpenSSH-formatted public key that you already copied.  After pasting, simply save the file and exit.

Your Linux server is now configured to authenticate your TPM-enabled SSH connection.  Now, in Windows, you need to set up your TPM-compatible software, in order to facilitate the SSH connection on your side.
In the text editor, the second line of text that you pasted earlier is the authentication string.  It corresponds to the private key on your TPM.  This line, beginning with cert:\\, is what you need to paste into PuTTYWinCrypt as described below.

Use TPM-accessible software to log in:

Open PuTTYWinCrypt.  Under the Category Connection : SSH : Auth, in the space that is labeled "Private key file for authentication," paste the text beginning with cert:\\.  Normally, without using a TPM, in this space you would paste in the path to your private key that lives on your hard drive.  But in the process that you're following here, the private key is safely stored in your TPM, which by comparison is much more secure.  Once you paste this text (beginning with cert:\\) in that space, you'll be able to authenticate with the same server that you installed the public key.  To persist your changes, remember to save your connection; in PuTTYWinCrypt, under the Category Session, click on the Save button.
In PuTTYWinCrypt, try connecting now via SSH.  If you configured everything properly, you should get a pop-up from the Virtual Smart Card on your TPM, asking for your PIN.  Input the PIN.  If the PIN is accurate, the SSH connection should continue and connect as expected.
You're done!  You just connected to your server over SSH with a private key that is safely stored on your TPM.

The above information was inspired by, and partially obtained from, an informative blog post by Chris van Marle.

One final note:  researchers at IBM are currently developing what they call Virtual TPMs, which will make it possible to migrate TPM functionality from one cloud host to another.


If you consider that the network between the VPN's endpoint and the OAuth2 server is safe (because request are reencrypted, or it's a "trusted network"), then an HTTPS tunnel or a VPN tunnel offers the same level of security (encryption and authentication).

However, as stated in section 3.1.2.1 of the OAuth2 RFC:

  The redirection endpoint SHOULD require the use of TLS as described
  in Section 1.6 when the requested response type is "code" or "token",
  or when the redirection request will result in the transmission of
  sensitive credentials over an open network.

So it's highly recommended to have the OAuth2 server protected with TLS. If it's not, some credentials could be intercepted on the local network of the company in case of misconfiguration of some network equipment.

Also not that OAuth2 expect to have TLS everywhere, so some things can actually not work. For instance, some libraries could refuse to use some endpoints of /.well-known/openid-configuration if it's not HTTPS.

So: it's highly recommended to enable HTTPS on your OAuth2 server, but in your case it is not mandatory.


Should email verification be followed by password-based login? Why?

You certainly should authenticate the user who clicks the link. Otherwise, as you say, someone could inadvertently confirm an email address. However, it is usually possible to authenticate the user transparently, so they don't need to enter their password.

The way we achieve this is using a session cookie. During the signup process, the new user is issued a session cookie. When they click the confirmation link in the email, they will usually use the same browser, so the session cookie will be attached. The web site can verify the user's identity using that cookie.


Denial of Service by SQL queries - are selective queries better than queries that return a lot?

You can mitigate both of these issues by creating a FULLTEXT index. In other words, instead of having the database system read the entire table and scan every character in every field, the system builds an index that can be quickly searched while discarding common words/letters. Your attacker can search for "e" as fast as they want, and the index will answer with no results returned in a matter of a very small fraction of a second (and with appropriate caching, future searches will cost even less). This can reduce the amount of searching needed from millions of bytes to just a few hundred bytes, which is a trivial operation for a computer.

Most FULLTEXT indexes tend to use a "b-tree" (or, binary tree) implementation. This means that even if your attacker sends 128 random characters, as opposed to just one character, the database only needs to go until it can prove that there's no matching values, which means it will not search all 128 characters, assuming we're talking about actual random values. The most exhaustive search that the attacker could perform would be to actually use real words from a dictionary that are also in your blog. You could also restrict searches to a minimum length by discarding words less than, for example, three characters long. This would make your index more effective and reduce the capabilities to spam small searches.

As far as "dangerous" goes, it's unlikely that either attack would cost very much in terms of cost assuming it were a personal blog-- the entire database can fit in memory and thus wouldn't contribute very much to server load even if it were being hit hundreds of times per second. You'd be more likely that a DDoS would occur simply because your server's OS can't handle any more pending connections rather than the limitation of the database itself. Most databases can handle hundreds of simple index queries per second, even on a home computer.


Strange GET request to my web application

This is trying to exploit a remote code execution vulnerability in ThinkPHP. So yes, someone is attempting to attack.
Yes, although this specific one is specific for ThinkPHP, there are also regularly vulnerabilities for Django
Yes, this is very common for web apps. This is not the only type of request to attack and a succesful attacker might change the log file so you don't notice there was an attack. In my opinion a publicy hosted web app which processes non-public information (this also includes usernames/passwords for login) should not be done for a school project, at least without professional consulting because of the risks like stolen data. Even with only publicy available information it can cause damage like costs for computing costs like when the attacker uses it as crypto miner (like in your case) and manages to spin up more instances.
FranTech Solutions seems to rent out servers. So it might be FranTech Solutions, it might be a customer of FranTech Solutions or it might be someone hacked a customer of FranTech Solutions.
Wether it is illegal or not depends on the juristication. But typically police will not be interested in attempts without significant damage. You might send a complaint to FranTech Solutions and if they get enough complaints they might or might not shut down the server or customer or they might or might not just inform the customer of the server that the server might got hacked and the customer might or might not fix the server.

Typically webmasters will ignore such log entries after making sure they aren't vulnerable because it is so common, especially if the website has more than 100 users.


Healthcare company uses keyloggers for security purposes. Is this normal?

It's hard to justify whether it is common or not, as it's unlikely one could come up with a reliable statistics.

What is for sure is that such an approach clearly exists. A security solution applied by a company depends heavily on its threat model, and there is such thing as insider threat (basically, when a malicious employee steals or modifies your data on purpose). Some organizations take it very seriously and choose complicated paths to deal with it, including permanent video recording in all rooms of their back office, screen recording, or, yes, key logging.

As a person who have once seen a surveillance camera in a restroom of a company also related somehow to healthcare by the way, I'm not surprised at all by what you've seen today. Healthcare companies always try to take the privacy issues of their customers very seriously, sometimes even overcaring about those.

Keylogger, which is, yes, usually meant to be a malware, is just a tool here. As with a gun, you can use it to steal something or to protect yourself. Guns don't kill people, people do; and keyloggers don't steal your data. Criminals do.

All that being said, under most circumstances for most of the aspects of the insider issue there are more effective solutions, and there are of course numerous pitfalls of such an approach, ranging from privacy issues (leading finally to low workforce motivation) to assumed inefficiency of such solutions without proper SIEM and UEBA systems, properly integrated with each other. See, when you're collecting all the key strokes from all your workstations, it's a huge amount of data a human can't look through on a regular basis, so you basically need to thoroughly analyse typical user behaviour models with some algorithms to track down what's unusual. This is a task generally rather hard to solve.

Once again, it depends on a threat model whether an organization will accept all the challenges, some of which are outlined above, and go this way or will stick to other options. Of course, if this way is too much for you, you're probably free not to accept a job offer.

(There's a chance by the way the organization you're talking about doesn't really accept those challenges and is just tricking you into thinking you're being watched and recorded, while in fact you're not. You'll probably never know that for sure, unless some amount of binge drinking with members of your information security team will happen eventually.)


How do mobile carriers know video resolution over HTTPS connections?

This is an active area of research. I happen to have done some work in this area, so I'll share what I can about the basic idea (this work was with industry partners and I can't share the secret details :) ).

The tl;dr is that it's often possible to identify an encrypted traffic stream as carrying video, and it's often possible to estimate its resolution - but it's complicated, and not always accurate. There are a lot of people working on ways to do this more consistently and more accurately.

Video traffic has some specific characteristics that can distinguish it from other kinds of traffic. Here I refer specifically to video on demand - not live streaming video. Video on demand doesn't often have those priority tags mentioned in this answer. Also I refer specifically to adaptive video, meaning that the video is divided into segments (each about 2-10 seconds long), and each segment of video is encoded at multiple quality levels (quality level meaning: long-term video bitrate, codec, and resolution). As you play the video, the quality level at which the next segment is downloaded depends on what data rate the application thinks your network can support. (That's the DASH protocol referred to in this answer.)

If your phone is playing a video, and you look at the (weighted moving average of) data rate of the traffic going to your phone over time, it might look something like this:

(this is captured from a YouTube session over Verizon. There's the moving average over 15 seconds and also short-term average.)

There are a few different parts to this session:

First, the video application (YouTube player) tries to fill the buffer up to the buffer capacity. During this time, it is pulling data at whatever rate the network can support. At this stage, it's basically indistinguishable from a large file download, unless you can infer that it's video traffic from the remote address (as mentioned in this answer).

Once the buffer is full, then you get "bursts" at sort-of-regular intervals. Suppose your buffer can hold 200 seconds of video. When the buffer has 200 seconds of video in it, the application stops downloading. Then after a segment of video has played back (say 5 seconds), there is room in the buffer again, so it'll download the next segment, then stop again. That's what causes this bursty pattern.

This pattern is very characteristic of video - traffic from other applications doesn't have this pattern - so a network service provider can pretty easily pick out flows that carry video traffic. In some cases, you might not ever observe this pattern - for example, if the video is so short that the entire thing is loaded into the buffer at once and then the client stops downloading. Under those circumstances, it's very difficult to distinguish video traffic from a file download (unless you can figure it out by remote address).

Anyway, once you have identified the flow as carrying video traffic - either by the remote address (not always possible, since major video providers use content distribution networks that are not exclusive to video) or by its traffic pattern (possible if the video session is long, much more difficult if it is so short that the whole video is loaded into the buffer all at once)...

Now, as Hector said, you can try to guess the resolution from the bitrate by looking at the size (in bytes) of each "burst" of data:

  From the size per duration you could make a reasonable estimate of the resolution - especially if you keep a rolling average.

But, this can be difficult. Take the YouTube session in my example:

Not all segments are the same duration - the duration of video requested at a time depends on several factors (the quality level, network status, what kind of device you are playing the video on, and others). So you can't necessarily look at a "burst" and say, "OK, this was X bytes representing 5 seconds of video, so I know the video data rate". Sometimes you can figure out the likely segment duration but other times it is tricky.
For a given video quality level and segment duration, different segments will have different sizes (depending on things like how much motion takes place in that part of the video).
Even for the same video resolution, the long-term data rate can vary - a 1080p video encoded with VP9 won't have the same long-term data rate as one encoded with H.264.
The video quality level changes according to perceived network quality (which is visible to the network service provider) and buffer status (which is not). So you can look at long-term data rates over 30 seconds, but it's possible that the actual video quality level changed several times over that 30 seconds.
During periods when the buffer is draining or filling as fast as possible (when you don't have those "bursts"), it's much harder to estimate what's going on in the video.
To complicate things even further: sometimes a video flow will be "striped" across multiple lower-layer flows. Sometimes part of the video will be retrieved from one address, and then it will switch to retrieving the video from a different address.

That graph of data rate I showed you just above? Here's what the video resolution was over that time interval:

Here, the color indicates the video resolution. So... you can sort of estimate what's going on just from the traffic patterns. But it's a difficult problem! There are other markers in the traffic that you can look at. I can't say definitively how any one service provider is doing it. But at least as far as the academic state-of-the-art goes, there isn't any way to do this with perfect accuracy, all of the time (unless you have the cooperation of the video providers...)

If you're interested in learning more about the techniques used for this kind of problem, there's a lot of academic literature out there - see for example BUFFEST: Predicting Buffer Conditions and Real-time Requirements of HTTP(S) Adaptive Streaming Clients as a starting point. (Not my paper - just one I happen to have read recently.)


/etc/sudoers file with permissions set to 640 instead of 0440: what does it mean?

As long as the file is owned by root:root, there's no security risk.
And your changes don't even matter.

You specified that root is not allowed to write to the file.

If not root, who else...?
root can change the permission back


Any reason I shouldn't be salting and hashing before putting through bCrypt?

There aren't any obvious security weaknesses with your schemes.  The original one (other than possibly not storing a version number with your hashes so you can upgrade your scheme to more rounds or a new pepper if necessary), or the new one layered with bcrypt.  Bcrypt can take 72 bytes of input so there's no problem using sha256 as your hash.

I would be careful if you encode the output of your keystrengthened sha256hash before feeding it to bcrypt.  In principle, its probably best to keep it in the binary form -- if you were using sha512, that would let all the bytes be used (as 72 bytes = 576 bits).  Granted with sha-256, it doesn't matter as long as you do it correctly.  A sha256 hash is 32 bytes long (in binary with non-printable letters), 44 bytes long after base64 encoding,  64 bytes long (in hexadecimal), but 88 bytes if you base64-encoded the hex-encoded hash (which would be partially truncated and slightly weaken security -- e.g., instead of 256-bits of inherent security you have 72/88*256 ~ 209 bits).

Note, if a user has an extremely high entropy password (e.g., 400-bits of entropy) that in principle would require ~2^400 time to crack, by using sha256 as an intermediate step it will only take time ~2^256 before its likely to find some password that works.  Granted 2^256 is completely secure these days (as is anything significantly over ~2^80, so this difference has no practical relevance).

It does get more complicated and potentially more annoying to maintain (granted you could argue this is a good thing -- if your database was ever leaked it would be harder for an attacker to get a GPU to brute force it).  If you ever upgrade your system and things don't work perfectly there are significantly more points where things could be going wrong.  If someone new developer comes along and see hashes are in the form like bcrypt, they may assume they are just bcrypt and change something that breaks the system.

An alternative would be to keep both systems in place and gracefully upgrade users to bcrypt on their next successful login.

def login(username, password):
    user = get_user(username)
    if user.uses_old_hash():
        calculated_old_hash = sha256_1000_round(password, salt=user.salt)
        if constant_time_string_compare(user.hash, calculated_old_hash):
            calculated_new_hash = bcrypt.hashpw(password, salt=bcrypt.gensalt(12))
            user.hash = calculated_new_hash
            print "Login Successful"
            return True
        else:
            print "Login Failed"
            return False
    else:
        hash = user.hash
        calculated_new_hash = bcrypt.hashpw(password, salt=hash)
        if constant_time_string_compare(hash, calculated_new_hash):
            print "Login Successful"
            return True
        else:
            print "Login Failed"
            return False


MSF Venom Reverse TCP-Shell: Meterpreter and Netcat Listeners not responsive

In the first screenshot, it seems that the session was opened but not started. To solve that, you can run the meterpreter listener on background then you can interact with session using its id (case of the first screenshot: 1).
You can start the exploit in background using the command:
exploit(multi/handler) > exploit -j -z

Once you got the message that the session was created, start interacting with the session by running:
exploit(multi/handler) > session -i ID_SESSION

For the second screenshot:
You are using netcat listener with windows/x64/meterpreter/reverse_tcp. It won't work because of the payload that downloads a second stage when it connect to the server.
In order to use netcat listener, you should use windows/x64/shell_reverse_tcp.


The cookie is what identifies the session so if it is stealed the session is stealed. What you have to do is to protect the application and the cookie to avoid being hijacked.

Use the HttpOnly flag
Use HTTPS
Use the secure flag
Use the correct cache headers
Don't use the cookie in the URL
Use temporary cookies

In general, you can use the OWASP Testing Guide v4 to protect the whole application and thus protect the cookies.


What other attacks can be deployed using IP spoofing other than DoS(and DDoS) attacks ?

The two major attack vectors that spring to mind are Non-Blind and Blind spoofing, which make use of spoofed IP's and TCP to take control of a IP/TCP session. Although the Non-Blind attack in particular may not be prevented by Source address validation.

When on the same subnet as an attacker, hijacking of a legitimate TCP connection is possible by sniffing the sequence and acknowledgement numbers of the TCP segments. By spoofing the target IP and corrupting the data stream, the session can be re-established by the attacker with the spoofed IP and sniffed the seq and ack numbers, thus hijacking the session. This is known as Non-Blind Spoofing

There is also an attack known as Blind Spoofing that is more sophisticated an only likely to be possible on legacy systems. This attack can be used when the sequence and acknowledgement numbers are unreachable by the attacker. By sampling packets sent to the target an attacker could predict the acknowledgement and sequence numbers, and thus hijack the TCP session. Modern implementations of the TCP protocol however use random sequence number generators making this attack vector unlikely to succeed.


Parameters to check before storing data on cloud

PART 1 (example)

Let's categorize your data as TOP SECRET , Classified and normal data.

If you would want to store TOP SECRET data in cloud, I would suggest
NOT to. Remember that in the moment you upload something online, you
are not the only one who have access to it. But if you really have
to, than it would be a good practice to encrypt your data before
uploading it, because remember:

IF YOUR SERVICE PROVIDER ENCRYPTS YOUR DATA, THE SERVICE PROVIDER CAN
DECRYPT YOUR DATA
If you would want to store Classified data, you must be sure you are
storing the data in a trustworthy cloud service with good reputation.
Here you have a study on the best cloud services.
If you would want to store normal data, then the common services like
Google Drive, Dropbox, One Drive are OK.

PART 2

In a general point of view you should know this things:

Make sure the cloud vendor is up-to-date on data center and industry
certifications.
Pick a provider that suits your needs. Some providers are specialized
in specific data types.
Take a look at bandwidth limitations (if you store business
data). If you are going to be using cloud as part of a backup
strategy, you need to understand the bandwidth limitations both for
the initial backup of a large amount of data, as well as what will
happen should you need to restore a large amount of data.
Make sure data is encrypted.
Carefully read the provider's SLA.
Know how much the cloud will actually cost you.
Make sure you can recover/restore your data in an efficient way.


Why has salt option been deprecated as of PHP 7.0.0?

It is not less secure because in absence of a manually provided salt, a securely generated salt is automatically created and used.  So, the option of providing your own, while it could be as secure, would never be more secure, and could very easily be (and probably often was) less secure if salt generation technique was poor.

If it meant that no salt as all were used, that indeed would be less secure, but thankfully that is not the case...You're just getting a more secure default configuration.


How do you test buffer overflows in the lab?

There's VMs available which include security challenges, as well as old CTF write-ups covering exactly how specific buffer overflows were triggered.
Here's one I found with a quick Google.
A VM called covfefe, and a Walkthrough which includes a buffer overflow.
This is just an example that there's tons of VMs and challenges out there for you to try. Jumping to exploiting real world programs is going to include a lot of protections that may make it difficult to compromise before you're sufficently experienced.


Outsourcing software development and its effect on security

I'd say that there is nothing per se which would always lead to outsourced software being less secure than an in-house development but there are some common factors which may in practice lead to this commonly being the case

Cost concerns.  If a key factor in winning the work is low cost, then the risk of insecure software is likely to increase.  Whichever way you cut it good software security costs money (IIRC Microsofts early SDL estimates was a 10% overhead), so where a 3rd party has to be cost competitive to win, non-functional aspects of the project (e.g. security may suffer).  This leads to the second point.
Failure to adequately describe the required security level in the contract.  A general problem with outsourcing is that the requirement has to be clear in the contract. Things which aren't in the contract are likely not to be focused on (see point 1). Specifying exact requirements for security in a software contract is hard.  Language like "it should be secure" isn't prescriptive enough to produce a good result, and the contracting company and outsourced provider are likely to have a very different idea of what "secure" is.
"Market for Lemons".  Along with that you have the general problem that in secure development there's a market for lemons.  What's meant by this is that it's very hard for a buyer to adequately assess the security practices of a development company.  There aren't really any good qualifications that can be assessed and buyers are unlikely to go to the effort of manually assessing the security knowledge of the individual developers.

All that said, I'd say that it's entirely possible for an outsourcing company to produce more secure software than an in-house team, the key would be for the buying company to actually prioritize security in a meaningful way during the purchase process, take efforts to assess the claims of the bidding companies, and have good descriptive security requirements in the contract.


Does RekeyLimit property in sshd_config enforce re-keying / key re-exchange?

Actually, this is quite interesting question.  I had to look into it, how does it actually work.  Direct initiation of rekeying using ~R works fine as you describe and it is expected.  If client forces rekey, it is also working, but the server side is somehow suppressed.  In the code, this variable is handled without special care and if I am right, the client offer overwrites the server's setup, which may not have be intentional and can be interesting topic on openssh-unix-dev list, if there will be no better answer.

It is not specified in the RFC4253, how this should be handled, so it is implementation detail.

However, the rekeying should not be needed to do more frequently than the default, because it stems from MAC sequence number wrapping [RFC4251].

Edit: Rekeying was reworked a bit and in openssh-7.2 should be working better.


Forgot password and revealing whether account exists

There is sometimes a trade-off between security and usability.

If it's important to you or your users that other people don't know they're using the site, then your second choice is the best one.

You can always send an email to an address that doesn't exist in your system, like "Someone requested a password reset for this address, but it's not in our system". That handles your second complaint.

Add a link to re-do the password reset on the confirmation page. Hopefully, they'll type in the email correctly the next time.

So, decide whether avoiding user enumeration is more important than the occasional mis-typed email address.

  What are the benefits not revealing whether a password reset email has matched an account

You don't give or confirm a list of users' email addresses to an attacker and don't let other people know that a given user is using your site. If it's a site about kittens, who cares? If it's a bank or extra-marital affair site, then this is important.

  How are these beneficial when registration requires email matches to be revealed?

Who says registration requires this? Do the same thing for registration. Request email address, send "step 2" link, or "someone requested a registration on our site but this address is already registered" emails.


How can I prevent that my users get a certificate issued for my domain on my behalf?

Update: It seems like a Finnish man was able to demonstrate this "attack" by issuing a certificate for the domain live.fi by having the address hostmaster@live.fi.

Last year, I made a bet with a friend that I can get a browser-trusted certificate with his domain name in order to launch a successful MiTM attack on his login form to steal his password. Long story short: I lost the bet; I wasn't able to convince any of the 16 CAs I contacted that I'm the legitimate owner of the domain. Even though I had an email account on his mail server and had FTP access to a user directory under the WWW directory.

Let's go back a little. What do CAs do before issuing you a basic certificate? They have a process called Domain Control Validation (DCV). The good news is that DCV makes it difficult for somebody to issue a certificate on your behalf. The bad news is that each CA can make custom amendments and modifications to the DCV, which makes it impossible to tell which CA will be the weakest link.

Generally speaking, CAs use one of the following methods:

1. Domain Email Validation: They will send you a verification link/code to one of the following email addresses:

Whatever email you have in the WHOIS records (if you have WHOIS privacy, they'll ask you to contact your registerer and setup email forwarding).
admin@YourDomain
administrator@YourDomain
hostmaster@YourDomain
root@YourDomain
webmaster@YourDomain
postmaster@YourDomain

2. Domain CNAME Validation: They will ask you to create a custom CNAME entry. It usually involves hashes of your Certificate Signing Request (CSR) or a randomly-generated key of their choice. An example of such entry is

<MD5(CSR)>.yourdomain.com.  CNAME  <SHA1(CSR)>.CA.com

3. HTTP Request Validation: They will ask you to upload a specific text file to the root of your domain. The file should be accessible with the following HTTP request

http://YourDomain/<MD5(CSR)>.txt

And it should contain SHA1(CSR).

Interesting findings: During my "challenge", I managed to get one CA (SSL.COM) to agree on uploading the text file to Domain/MyUserName/Something.txt and email me the verification link to MyUserName@Domain. However, they insisted that they must verify me with a phone call to the number in the WHOIS records. I also found out that some CAs require a phone as a first-step verification, even before the email verification. Such CAs don't issue certificates for domain names using privacy options.

So, to directly answer your question, prevent your users from creating special email addresses (mentioned above. You also might want to add it@, hostadmin@, etc; prevent your users from creating CNAME entries; and, finally, prevent them from adding files to the root of your domain.

Note: Just because 16 CAs turned out to be good, it doesn't mean that there aren't ones out there that are willing to compromise in the name of "customer convience".


Android, how do I prevent Confused Deputy Attacks?

The root of the confused deputy problem is an application performing a sensitive action on behalf of a malicious user.

In the context of an android application, it is possible for an application to be launched with arguments.  In this case an argument would be an attack surface that could be vulnerable to any sort of input validation vulnerability,  including confused deputy attacks.  In short,  no android app should trust this input or perform an elevated action on behalf of the caller.  Doing so would be a vulnerability.

If an android application is a webview,  then it could be vulnerable to XSS, CSRF.  These two vulnerabilities use the browser as a confused deputy and is discussed on the confused deputy problem Wikipedia page above.


How does mitmf-filepwn implement dns-spoofing?

Google.com (and all other country versions like google.gr) do opportunistic HSTS (see this answer for more details). It is an interesting question though, why they would stop enforcing https from their chrome browsers (as it used to be like that in the past).

Facebook does strict HSTS, which is why you will 'never' be able to force the client into http mode for Facebook. AFAIK, Linkedin does not use HSTS, so something else must have gone wrong there.


Is it possible for guest system to spy host system when using virtual maschine (VMware)

Ostensibly, the answer is no. The architecture of most virtualisation platforms abstract the activity of the virtual 'guest' machine from that of the physical 'host' machine. There are, however, a couple of caveats to this:

Primarily, you are reliant of the security of your virtualisation platform, the major players (VMware, Microsoft hyper-V, Oracle) all have very good security track-records for host segregation, and I'm not aware of any publicised flaws. That said, the fact that the guest machine's processing and memory are still intrinsically based on the processor and memory of the host machine means that there could be exposure were flaws to exist in the software; this is however theoretical.
Host Tools. Most virtualisation platforms provide some form of tool/service which runs on the Guest OS and allows limited communication between the virtualisation service and the guest (e.g. VMware Tools). Again, whilst I am not aware of any identified flaws that could allow the breaking of the 'virtual curtain', it wouldn't be beyond the realms of possibility.

In this instance, I would suggest that you can get a very high level of assurance around the separation of your host and guest through the use of a current version of one of the major virtualisation platforms.

I hope that helps.

Brendan


First, you don't "encrypt with a certificate". You encrypt with a protocol which may or may not use certificates for public key distribution. The most commonly used protocol for protecting bidirectional data channels is SSL (now known as TLS). In SSL, there is a client and a server, which need not correspond to the "client" and "server" at the TCP level: the SSL "client" is the one who begins the SSL handshake, i.e. who sends the ClientHello message.

In SSL, the server normally shows its public key as part of a certificate. The client validates the server's certificate (it checks that it is issued by a trusted CA) and verifies that the certificate indeed contains the intended server name. This means that the client has some guarantee that it is talking to the right server. On the other hand, the server does not know who the client is; the server just has the guarantee that it is talking with the same client during the whole connection.

If the server must know who it is talking to, then some sort of client authentication must be applied. SSL supports client certificates for that. Another method, very often employed in a Web context, is to have the client show some credentials (a login and a password) inside the SSL tunnel (since the client has some guarantee that it talks to the right server, then it can send the password to the server without fearing interception by an attacker).

SSL also supports some certificate-less connections, e.g. the PSK cipher suites, in which client and server authenticate each other with regards to a shared secret value; if, in your situation, you can arrange for client and server to know a common secret key, then this will avoid all the certificate business. If the shared secret is a low-entropy value (e.g. it is a "password" that a human user will be able to remember and will accept to type occasionally), then SRP cipher suites are the way to go. PSK or SRP support in .NET may require some extra libraries, though (e.g. OpenSSL bindings for .NET).


Although in theory modelines shouldn't allow you to do anything bad, sanitizing modeline functions input is hard. There have been several security issues in the past that allowed arbitrary command execution or DoS attacks. To cite a few past vulnerabilities I could find:

CVE-2002-1377 allowed an attacker to execute an arbitrary command
CVE-2005-2368: arbitrary command execution using glob and expand functions
2007 (couldn't find a CVE number): DoS through the spell checker
CVE-2007-2438: shell command execution through writefile, feedkeys and system
CVE-2016-1248: arbitrary code execution again using filetype, syntax and keymap
CVE-2019-12735: one more arbitrary code execution, by breaking out of the sandbox

While I believe they have all been fixed, new vulnerabilities keep popping up and it is likely that similar vulnerabilities will be found in the future, which is why distros disable modelines by default (at least Debian and SuSE do).


Downloading a video without website noticing that you're not just watching it?

You are asking the wrong question.  The right question is:

  How a website knows if a video has been watched or downloaded?

And the simple answer is: It cannot know for sure.

The example I'll use for this argument is the way how most Linux users watch videos.  The backend of video display on Linux is today ffmpeg (which is used by mpv and vlc as well).  The backend supports youtube URLs by means of youtube-dl (and youtube-dl is/can be used in VLC).

When a user types (or I do it, since I just typed this to make a test):

mpv https://www.youtube.com/watch?v=B3NcgOs0LYo

The video is downloaded to my machine before playing.

Browser note

But wait, when I watch a video through a browser is isn't being downloaded right?  Wrong.  When you watch a video through a browser the video is downloaded to your machine alright before being displayed.  The video need to reach your machine's memory at some point to be played.

Therefore there is (almost) no difference between using a streaming player (vlc or mpv) and watching from a browser.  There are just a couple of differences.  When you watch through a browser you also see the rest of the website, the banners are fetched, the JS is executed.  If someone on the streaming website can look at the webserver logs he can conlude whether you saw the page through a browser or not (stream players do not have JS engines).

Conclusion

A website maintainer can tell if you looked at a webpage or not when you were watching the video.  He can, therefore, tell is you used the browser interface to his website or a streaming player.  But he cannot tell the difference between a streming player and a download, because the steaming player already performs the download anyway.

Can a website claim that stream players are the same as downloads of a video?  Not really, the number of people using stream players is big, notably VLC.

One of the biggest reasons that people started using streaming players was to escape from using the Flash Plugin (which is famous for being particularly buggy in terms of security).  This is less of a problem today (with HTML5 streaming implemented widely), but still a reason why so many streaming players are used.

Disclaimer: When DRM comes into play things change.  Unfortunately (fortunately?) I have almost no experience with DRM