Is it possible to detect password length from hash? Does doubling your password add more security?

If the length of the hash varies depending on input, then it is not a hash. A cryptographic hash function, by definition, offers a fixed-size output, regardless of the input. For instance, SHA-256 offers a 256-bit output, always; never more and never less.

Password hashing is a specific activity which is often discussed in this site. The short answer is: use bcrypt. It handles the fine details properly -- and there are many.

As for "doubling" the password, it adds security only insofar as you may elect to do it or not to do it, thus doubling the size of the space of possible passwords. If you do it systematically, then no, it does not increase security. Also, password length may leak (when you type a password, your office colleagues may easily hear the number of keystrokes, for instance).

The strength of passwords does not come from length or special characters or other traditional rules; a password is exactly as strong as it could have been different. The number of possible values for a password (given your method for generating the password) is the key parameter. Anything "witty" here is a bad idea: remember that we must assume the attacker to be always as smart as you. So don't try to make passwords with an idea of "the attacker will never think of that !": the attacker already thought of it, before you.

A good password is generated randomly, with dice, coin flipping, your cat chasing a toy mouse over a plank which has been divided into numbered areas, or even, should it come to that, with a computer running a random number generator.


The answer is simply; the salt is stored alongside the password hash. A typical database scheme would look like;

uid  | username    | password         | password_salt
-----|-------------|------------------|--------------
0    | alice       | 862a6c81b7f8361b | 71e9c02731

The salt is not a secret. It is there to make certain types of attacks orders of magnitude more difficult.

This answer should contain everything you need to know.

If not, then this answer has even more information on the ins and outs of salting.


what is the security issue if session time out is the default value from server configuration?

A pen test might interpret the presence of default timeout settings as an indication that you forget to set it.

Timeout should be set in a manner that is specific to the application.  For example, if you handle credit cards, PCI-DSS requires a 15-minute idle timeout.


Is there a risk associated with to many entries in your SAN list?

The risk is that all those websites share a public key and private key. That means that any of those sites could impersonate / man-in-the-middle another and you would still get the HTTPS padlock. For example, you could be browsing newrepublic.com, but if somehow your traffic was actually going to robertwalters.cn, your browser would have no way to tell.

That said, it's becoming quite common for companies that host more than one site to put them all on the same certificate. This saves costs; both the costs of purchasing the certificate from a Certificate Authority, and also annoyance of each cert expiring and needing to be renewed at a different time.

This is getting even more common with massive hosting providers like CloudFlare who host (or at least provide front-end services) for thousands (millions?) of websites. In these setups, your the HTTPS connection is between your browser and the CloudFlare front-end, and your traffic flows through CloudFlare's backend unencrypted. Since CloudFlare has the private keys for every website it fronts, does it really matter if they're all on the same cert?

Really what that tells you is that those sites are all hosted by the same provider. I don't think there's anything to worry about here.


Prevent a desktop client application from abusing an API access token obtained through OAuth2 on behalf of an application

Giving the desktop client the keys to the kingdom is by definition a violation of CWE-602: Client-side enforcement of server-side security.  Any piece of software running on an attacker's machine cannot be trusted.

There needs to be an intermediary API,  a web service that you control, and provides the ability to enforce user-based access control to a communal resource (files on DropBox).

You may also want to read the DropBox Terms and Conditions ,  which forbids resale of their service.


As someone who runs personal honeypots and used to defend a massive global corporation, I can tell you that any attack leaves fingerprints. Styles of commands or command sequence, coding style of malware, as well as the paths used by attackers can all point in a direction of an attacker.

For example, I was able to positively identify someone trapped in my honeypot because they used their real name as their password (they didn't know I was recording their keystrokes). Using various correlation methods, I was able to attribute the pseudonym they were using on the site they used to distribute malware to their name, including finding out that they used the pseudonym on a single's site 2 years ago that they had deleted (but Google's long memory did not forget).

Once you start studying live attacks, you can really start to see the people "behind the keystrokes" and that's one reason why I continue to operate honeypots. I think I can tell whether an attacker is Asian or Eastern European, simply by their methods, and not by their IP. If I had enough data from a known attacker, I believe I would be able to recognize their actions in a new environment.


Why is a valid SSL certificate required for SSL-Strip?

SSLStrip can work of one of two ways:

  It will transparently hijack HTTP traffic on a network, watch for HTTPS links and redirects, then map those links into either look-alike HTTP links or homograph-similar HTTPS links.

The video is talking about the latter.  So you can still use HTTPS, but try to fool the victim into going to https://www.gmail.attacker.com.  Where the attacker owns a valid SSL cert for *.attacker.com.  A valid SSL cert isn't required if you're simply replacing https links with http links.  i.e. https://www.gmail.com with http://www.gmail.com

http://www.thoughtcrime.org/software/sslstrip/


Concerns and Gotcha with Secure Programming Standards Development

A few issues I found developing a team's secure programming guide recently:

How will the guidelines be enforced or encouraged? Who will be responsible for ensuring that products developed in accordance with your guidelines? You need to ensure that this person can:

see whether the guides are being adhered. This means they need to look into code reviews and testing results. And that means that the code reviews and tests need to exist and be performed :).
"throw an exception" in the development process. They need the authority to say no, this build isn't secure, it can't go out.
inspire the team to take security seriously. It sounds like annoying management-speak toss, because it is, but you don't want your developers doing security begrudgingly (not least because they then become disgruntled employees, and you double your security headaches). This is particularly important if the "owner" of the app's security is an outsider to the development team, e.g. if you have a cross-cutting security team who get seconded to dev projects.

Related to the above, how will management be seen to be taking security seriously? If they aren't then it's a social hint that the employees don't need to either. What are the rewards for committing to the standards?
What feedback will you get on how the guidelines are working? You really want to understand:

What vulnerabilities were discovered during release
What vulnerabilities remained in the product, and why
The hard bit: what time was spent doing things that meant adhering to the guidelines but didn't impact the security of the product sufficiently to justify their cost? The closest measurable quantity I've found is "are we spending time on mitigating things that aren't in the threat model?", though spending lots of time on low risk items compared with higher risks is another red flag.

How will such feedback be acted upon? Can the developers make changes themselves if they find an issue, or does it need to be escalated?


NetFlow IP Spoofing/Reflection Attack Detection

The IP would be spoofed before NetFlow could analyze it, so no. See here (https://en.wikipedia.org/wiki/NetFlow) for NetFlow info and here (https://www.us-cert.gov/ncas/alerts/TA13-088A) for DNS amplification. The attack must be configured such that IP Spoofing occurs before the router, which is where NetFlow is installed. We know this works because MiTM works. The IP would be spoofed before NetFlow could analyze it, so everything would look valid.


On a stock Android OS from a major vendor it's very unlikely that there will be a function which allows hiding an app completely. Since Android is open source though there's always the possibility someone creates a version with a kernel mod that allows the user to specify certain apps should be hidden and not listed.

One naive way of hiding an app is to use a third party launcher which doesn't list the app on the launcher. This doesn't fully hide the app though as it would be visible in the list of installed apps. One such example would be the Nova Launcher.

There are apps called "lockers" which attempt to disable or hide apps until they are unlocked. There are many of these apps and some may be more successful than others, especially if they require a rooted device. Some third party Android firmwares such as Lineage OS have this option built in by default.

There's another app I ran into that claims to copy a target app I to itself and run in a sandbox like mode. This would make it appear as if the app being protected wasn't installed.

Note: I am not recommending any of these apps, I'm simply including their names as examples of their type of solution that is available.


How does driver install with an expired cert?

From what I read in the comments and in chat I think this is related to timestamping. The driver has been signed at a time the certificate was valid. That signing time was confirmed by a certified timestamp server.

In that case, the driver is considered as trustworthy, since everything was fine at the time of signing.

To check for a timestamp, open the file properties in Windows Explorer, go to "Digital signatures" and check if there is a countersignature with the timestamp. It should look like this:

Your application (installer), however, was

not timestamped at all
or the timestamp was not provided by a trusted timestamp server
or the certificate itself was revoked to a time before the timestamp was created
or the certificate is not trusted by a CA

so that a warning UAC dialog is shown.


Do I need to secure a computer from physical attacks when attackers can already harm in many other ways?

Security is necessary in order to counteract "risks" to a system. You need to determine what those risks are and if "loss" in that area is acceptable.

Presumably, this train set up is not public, but in a locked building where people need a key to enter, or if allowed in, are monitored by other people watching. Yes, it is possible for someone to come in with a hammer and damage your trains, but that person is observable. An unsecured internet-connected computer potentially leaves the door open for someone to "walk in" and do damage, completely unobserved. This anonymity increases the risk that someone would do damage if they gain access (no consequences). In my opinion, it is harder to do damage with a hammer than with a computer (once access is gained).

A BIOS password is important to protect the machine against someone infecting the machine while they have physical access. There are other more important considerations if the machine is accessible by the physical public.

If it doesn't matter that someone could take over the machine, then no, security does not matter. But I suspect that it matters more than you think. But, YOU need to consider all the risks and the costs if those risks are realized.


Windows Fine-Grained Password Policies (FGPP) - Set Policy Duration

FGPP provides password policies, but does not to my understanding provide a means of applying to groups, OU's, etc. only for a defined period of time.

That said, I am curious why a group would have a temporarily shorter (assuming your domain setting is longer than 10 days :) )password age?

It seems to me the only way to accomplish this would be to apply a FGPP to an OU, then use an AD-automating method to periodically test the accounts' last password change value and move it to another OU based on that. I am not an AD "expert" but I am aware of tools that may make doing so possible.


Is it possible to keep your harddrive data safe from being copied and recovered

Yes, it looks possible. I assume you are talking about a USB device.

First, if you have autorun still enabled, the device can present itself as a drive configured for automatically executing the binary that will simply copy all files accessible to it, and maybe try to make a full disk copy.

Then, if you happen to have Windows unpatched, there were some USB driver vulnerabilities out there and exploits for those. Stick a device in and bang, owned.

Regarding the data decoding -- there is not much to decode if one gets a full disk image, he can simply mount it in Linux or whatever.

EDIT: Some CVEs for reference: CVE-2013-1285 CVE-2013-1286 CVE-2013-1287 CVE-2013-3200

And some recreational reading.


Are there any circumstances where I would need to generate a new revocation certificate for my PGP key?

The revocation certificate is for your Certify ("master") key, which does not change regardless of any subkeys or identities you add.


The problem your friend experiences does not look like "SIM card cloning". Two signs which may indicate that someone has cloned your SIM card are the following:

You see in your billing statement the calls/texts made from your phone which you did not make (however if you have a smartphone, this may also indicate that there is malware app running there, which generates those calls).
When your friends call you, your phone doesn't ring although they hear the phone is ringing. And when they text you, you do not receive texts (but if you turn your phone into airline mode and turn it back, you will receive the text sent after that).

If your SIM is cloned, nothing you could do with your phone would help; resetting the phone is completely useless. You should go to your operator and get a new SIM.

Now, regarding your issues:

  How I knew it was a hacker? unable to receive phone calls,

May be a network problem. However if the calls get through and someone else picks up the phone, may be the result of SIM cloning (but make sure someone or something did not enable call forwarding service)

  sms text message slow,
  screen changing on its own

This has nothing with SIM cloning.

  not being able to receive text message from some of her friends

If this means "I cannot receive texts from anyone from 2-3pm, even though I see in my billing the texts were received", this may be SIM cloning.

  sometimes receive a weird text WAP_push, etc

This looks more like malware or incompatibility between the handset and cell operator.


Looking for a way to overwrite a symbolic link

No, that's not exploitable. Write permission on links is worthless in practice. To re-target a link, you need write permission on the parent directory. To modify the file or directory that the link is targeting, you need write permission on the target. Write permission on just the link lets you do neither of these things.


Should LastPass use the YubiKey public identifier as a secret key?

No, this is insecure as the public identity is not considered a secret. This is backed up by the fact Yubico send the identifier over HTTP. If this is known to be used for a LastPass account, a MITM could capture the extra offline encryption key as used by LastPass.

Although there is a chance that it has been leaked over the internet, as the master password is also required to unlock the local password vault, the risk is low.

The YubiKey Personalization Tool can be used to configure a new public identity in the case that it has been leaked.


DNS Hijack: Only spoofing sites listed in etter.dns

Comment out the following lines in /etc/ettercap/etter.conf

  redir_command_on = "iptables -t nat -A PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"

  redir_command_off = "iptables -t nat -D PREROUTING -i %iface -p tcp --dport %port -j REDIRECT --to-port %rport"

Note: You will need these lines uncommented if you plan on running SSLStrip.


Pay for another cheap VPS and install nmap, w3af, etc and any other tools there. Then you SSH in and run your tests. You could also schedule the tests to happen automatically and email the results.

This is not a pre-made service, but it does accomplish what you've asked for with a handful of tiny scripts, done more cheaply and with more control than a paid service.


Difference between VPN server and Tor node server

In a way you are comparing apples with trees. VPN is not a specific technology but a general concept with multiple often significantly different implementations. Tor instead is a concrete protocol.

But VPN is essentially an encrypted tunnel between two communication peers. If the clients is putting multiple encrypted tunnels inside each other (not after each other but inside) you essentially get something like Tor: you have multiple layers of encryption done by the client, the client defines which path through the VPN the data take and only the final exit node of the VPNs can see the original traffic - all others see only traffic encrypted from another VPN.

There are some significant differences though: when manually putting multiple layers of VPN inside each other one defines usually only a single path through the network. Tor instead will take care that different connections take different routes involving different exit nodes and also different intermediate nodes.  This increases the level anonymity since creating an association between different flows is way harder even for an advanced attacker if all flows go a different way than if they would use all the same way through some multi-layered VPN setup. Additionally the protocol used by Tor is specifically designed to bypass deep inspection, i.e. it can mimic other protocols so it does not get blocked and it also has some protections against analysis of traffic patterns. These are all things one does not find typically in common VPN implementations.

Apart from that VPN usually work at the network layer and thus covers any IP traffic while Tor only covers TCP traffic and only for applications which are specifically designed to send the TCP traffic through something like Tor (for example by using Tor as a SOCKS proxy). Insofar Tor is from the configuration more comparable to a proxy instead of a real VPN. This kind of setup has the additional advantage that OS fingerprinting at the IP or TCP level is not possible, i.e. all what gets fingerprinted this way is the OS of the exit node.


Is there a maximum allowed key size in the USA?

Roughly speaking, no, the last statement is not true.

See this site for extended information about laws on cryptography in the USA (the same site contains a lot of information for crypto laws in other countries as well).

AES accepts three sizes of keys: 128, 192 and 256 bits. The smallest of the three is already way beyond that which can be broken through brute force (see this answer) so if the USA are "putting limits on encryption strength" then they are not making a good job of it. In fact, AES has three different key sizes mostly for compliance with inflexible (and old) US military regulations which call for three different "security levels". That kind of regulations made sense in the pre-computer era, when you had to choose between security and efficiency (there was no known cryptographic algorithm at that time, which would be both secure and sufficiently practical for generalized field usage). Since none of these regulations states that the "low level" has to actually be weak, NIST went for three key sizes, the smaller being already large enough to defeat Earth-based attackers.

Generally speaking, US laws are mostly about export, not domestic usage. There used to be a ban on large key lengths (and that one enforced key lengths small enough to be practically broken). Things have changed, though; the current state of US laws is that they don't depend much on key length. This relates to the growing realization from the US lawmakers that trying to enforce a ban on strong crypto is unlikely to work; having a system which keeps track of existing products is a better idea, and making all these products "legal" can only help.


Yes. The latest version of ModSecurity, 2.6.0, allows specific arguments to be disabled on a per-rule basis. This will allow easier tuning to the app for removal of false positives (and since it's not just the whole URI per rule there will be less, albeit still some, false negatives).

You'll notice that some MVC/MVP apps lean on the controller-action-id paradigm, which doesn't use parameters (except on the URI like you describe).


concrete real-life examples where grsecurity prevented an exploit

I'm root@anapnea.net, and grsec is the reason I can sleep at night.

As an example of an exploit blocked by grsec, you can look at almost any of the recent kernel vulnerabilities. Stock exploits simply don't work against a grsec kernel.

As an example of a vulnerability blocked by grsec, and in particular UDEREF, you have the recent x86_32 local root.

Grsec (minus rbac) won't do anything against "logic" problems (shellshock, hearthbleed, the LD_* problems) but, together with an hardened toolchain, it makes some classes of bugs much more difficult to exploit.

What it does help against are kernel bugs.

Then you have RBAC. Rbac is a MAC (mandatory access control) system, like SELinux or AppArmor, which offers further protection, even from root.

Plus, grsec will allow you to enable some nifty restrictions which are really useful if you can bear them. The main ones are:

socket restrictions (no listen/no connect/nothing)
/proc visibility restriction (per user)
stronger chroots
restrict runnable programs to only root-approved ones

The point is: grsec will make your system safer, but bugs will be found even on the safest system.


what to do if your online banking has low security standards

Probably the best you can do is contact your banks branch manager and share your concern.

If he may understand and can share your view, he may take it up the hierarchy up-to CISO.

If they find it to be a serious concern they would look at the possibilities to improve it. Which involves efforts and financial budget..since it may require to change or upgrade their systems.
If they don't find it to be serious...u may keep banging ur head.

As for the any regulatory authorities I guess they can always only provide guidelines, can not force. since the security requirement is a personal choice of the individual, not a matter of govt body. Customers are always free to check all the details before becoming a customer. Check if ur netbanking form that u signed at the time of enrollment gives u any option for raising such concern.
U may consult an attorney for help. Banks and any service provider for that matter are free to choose any kind of computing as well as security mechanism they may find deem fit for their requirements.
If you feel you've been victim of cyber attack on ur banking account and that u can prove with solid evidence that it is due to the negligence of the bank and the way they have setup their IT systems, then man ur in commanding position. You may sue them for such negligence.

I don't think with the given information it can be claimed to be insecure.

change the bank if you are not happy with their services and ur so paranoid with their IT security. But this time study the potential bank's IT systems and other aspects of the services more thoroughly, so u don't end up being so paranoid.


What are methods for preventing browser hooking / drive-by downloads?

Keep your system up to date,  but that is obvious and wouldn't help you with the IE 0-day last month.

The majority of browser based exploits require JavaScript in some capacity. NoScript helps mitigate these attacks.

The Google Safe browsing API is used by Firefox and Chrome by default to prevent you from reaching a site that is known to be leveraging browser based attacks.  However this does nothing for a targeted BeEF attack.

Some Anti-Viruses will plug into your browser and prevent an exploit from loading.  This could prevent a targeted BeEF attack.  But AV's aren't perfect and can be fooled.

Plan on failure, consider doing most of your day to day browsing inside a VM.  Restore this VM to a virgin state on a regular basis (once a week,  or once a month).  Assume that you have been compromised and change your passwords regularly.


Are any and all software vendors who have stored credit card information in their databases subject to PCI-DSS or only some?

First off - PCI-DSS applies to environments, not products.
In other words, it would apply to your website, but not the packaged product you sell to your customers.
On the other hand, it could apply to your customers, who would then need your product to fit in with their compliance.

To this end, the PCI fellows introduced PA-DSS - this applies to products, which can be installed in customer environments (which would then be required to comply with PCI).

Now, regarding your specific product - PA-DSS would absolutely apply, since you store or process card data (even without processing payment).

From the PA FAQ:

  For the purposes of PA-DSS, a payment application eligible
  for review and listing by the PCI SSC is defined as an
  application that:
  a)  stores, processes, or transmits cardholder data as part of
  authorization or settlement;
  and
  b) is sold, distributed, or licensed to third parties


Most legislation and regulations will not prescribe specific time frames for preserving logs.  For example the National Archives Records Control Schedules (RCS) vary according to the document type and are adjustable by agency mission and organic legislation.  If you can't find better, the FEDERAL RCS are an authoritative basis for specifying retention time frames.  David Swifts's paper in the SANS Reading Room Successful SIEM and Log Management Strategies for Audit and Compliance provides detailed and thoughtful guidance.

  A general principal of compliance is to have a written policy. Auditors then check to confirm that the written policy is followed. By defining
  and documenting our events of interest (EOI), and providing a written copy to auditors, we improve our overall compliance, and meet our requirement for a written policy. Then instead of being held to someone else's interpretation of
  the regulation, provided of course that we have a legitimate supportable set of EOI definitions, we will be measured to an agreed up on standard.

Be sure to include your auditors in this decision or face the possibility of an adverse finding later. If they decline to participate, document that in writing; don't count on auditors "remembering" later. Verbal agreements are only worth the paper they are written on. Also carefully document the decision process (meetings, references, participants, and policy statements) to head off negative findings years later.  The three critical inputs for preparing documentation for audits are: actions, actors and artifacts.

Note that records pursuant to the legal prosecution of a bad actor will extend their retention requirements for years beyond the conviction of the perpetrators, even to include the term of their sentence should appeal and parole hearings ensure.

The Appendix 2 of the RSA Best Practices in Log Management for Security and Compliance cited by schroeder has a comprehensive list of events and compliance expectations.


Something that may interest you are "googledorks"; these are searches people execute to find various things on the web.  Googling for "googledorks web camera" will give you many signatures that people search for when looking for web cameras on line.  If you were to configure your honeypot to respond to those URLs, you might catch him trying to find your web cams.

To find suitable honeypot software, simply google for "honeypot web cam" and you should turn up several applications you could run.  http://mushmush.org/ has a few specialized open source honeypots, including SNARE and TANNER.  You set up SNARE by running a script that "clones" an existing site; all you should have to do is clone your webcam's access page.  https://zeltser.com/honeypots-for-malware-ssh-web-attacks/ also has a list of honeypot software, but it's getting a little old.

Before you run off and invest in setting up a honeypot, consider what you will do with the information you learn.  Vigilante justice is probably illegal where you live; and most local police won't be interested in a minor computer crime unless there's other evidence to go with it.  And confronting the perpetrator yourself may put you at risk of violence.  Please be careful with the information you obtain.


Service changing port when scanned with nmap

This sounds like port knocking. Port knocking is where you connect to a sequence of ports before a port is exposed that allows you to connect to a specific service.
Some people like to use it as an extra security measure to lockdown SSH.
For example lets say I've configured my server to listen on port TCP/1111, then when someone connects to TCP/1111 it will open TCP/2222 and so on until finally port TCP/22 opens and I can SSH to my device.
You can read more about how this works in the below link.
https://www.howtogeek.com/442733/how-to-use-port-knocking-on-linux-and-why-you-shouldnt/


Are the rules used to validate certificates in the major browsers documented anywhere?

What browsers do is subject to change at the whims of whoever maintains them, and they do so without any proper documentation.

The treatment of wildcards in dNSName entries in certificates is formally defined in RFC 2818, which would imply that, e.g., *.*.example.com would match a subdomain name that's two levels down example.com; it also says that f*.com shall actually match foo.com but not bar.com.

It turned out that browsers don't follow these rules, for a variety of reasons which have never been fully documented, but which mainly fall into two categories:

"Security reasons"
Laziness

"Security" here means "we ran into some abuse and changing the rules on the fly looked like a good idea at the time". For instance, once somebody produced an *.com certificate, somebody figured out that it was not a very good idea, and found it expedient to simply forbid it in the browser code. An important point to consider here is that browser vendors and commercial CA are not the same people; from the point of view of a browser maintainer, if something must be done quickly (e.g. within 24 hours, not 24 months), it must be done in the browser itself. Security issues related to browsers tend to be highly publicized and quite damaging to the browser's image, so this call for prompt reaction, which usually (and unfortunately) precludes good documentation.

Laziness is probably at fault for the lack of support of "double wildcards" like *.*.example.com. In all generality, if you want to implement support for expressions with several wildcards, you have to do it with nested loops (to explore all possible matching combinations). Restricting wildcards to a single "*", moreover at the very start of the name, makes the implementation much simpler.

An additional fact to take into account is the paralyzing property of "security". When something has been done, or seems to have been done, in the name of "security" then many developers lose all initiative and are extremely reluctant to modify it -- because they know that any mishap related to security entails full blame.

RFC 6125 tried to document existing practice, although it varies quite a lot depending on browser (and OS, since some browsers delegate certificate validation and processing to the OS). Note that RFC 6125 does not really forbids more than one * in a name; in fact, an errata has been submitted about that, and the editor put it under the status "held for document update", which really means "good point, we'll fix it in a later RFC".

While RFC 6125 lists requirements on the browser side (consumer of certificates), the CA/browser forum also considers the CA side (producer of certificates). The Baseline Requirements seem to imply that only a single * may occur, and only at the left of a name (but this is not very clearly stated).

While there is a lot more to certificate validation than wildcard name processing, all the business around the * character illustrates quite well that nothing is firmly documented, and browser vendors have already taken the habit to do things first, and document things only much later (if at all).


PPTP is incredibly insecure as you've stated and provides next to no security whatsoever, there are tons of vulnerabilities in it and should be avoided at all costs. You can read more about those vulnerabilities here if you scroll down to Security

L2TP should always obviously be used with IPSec because L2TP doesn't actually feature any encryption if you run it as a standalone, which is why you will mostly see it paired with IPSec.

IPSec tends to be pretty secure. Below is a list of the Cryptographic algorithms it uses:

Authenticity & Integrity Protection: HMAC-SHA1/SHA2
Confidentiality: 3DES-CBC it can also use AES-CBC and AES-GCM. It is worth noting that AES-GCM will also perform authentication, so that could be a reason for choosing it.

IPSec will also perform a Diffie Hellman exchange before data is ever sent across a link.
You can refer to RFC7321 to learn more about IPSec, here is a very, exceptional article on the Cisco forums on how it works, I'd highly recommend reading it as it goes into a lot more detail than my post.


I want to hire someone on Upwork to install a bitcoin trading bot on a cloud server. What vulnerabilities should I watch out for?

If you give them unattended access for any amount of time, you can't.

What you can do is for example to give them access to your desktop using some remote desktop software, then connect to the cloud server from your PC.
If you watch them all the time, you can be sure there is no backdoor, if you understand everything they do.

Most likely you won't understand everything they do, else you'd just do it yourself. But at least you would notice maybe suspicious actions.

Many screen sharing tools also allow to record the screen. This way you could show the recording to someone else to check that no backdoor was installed.

The important point is that you never allow them to access the server on their own and watch everything they do.


Windows manages certificates and private keys separately. Each certificate may point to a private key; several certificates can point to the same key. Each such "pointer" is given as the name of the Cryptographic Service Provider (that morally contains the key), and the key name within that CSP. Windows does not keep track of how many certificates point to a given private key, and indeed this is not completely defined (especially since certificate stores can be extended with custom DLL). The main consequence is that when you delete a certificate, the private key stays there.

Private keys can be destroyed, but this requires calling the Win32 function CryptAcquireContext() with the CRYPT_DELETEKEYSET flag. Alternatively, you can use the certutil -key command to list private keys, and certutil -delkey to delete them. Neither of these commands is described in the Certutil documentation but you can get some help with certutil -key -? and certutil -delkey -?. In both case you may need to specify an explicit CSP name with the -csp option (use certutil -csplist to get the list of CSP installed on your machine).

Anyway, the security implication is the following: don't rely on private key deletion. A private key is a sensitive object; it must be handled with care. The normal lifecycle for a "machine key" is to be generated on the machine where it will be used, and never leave it. You should arrange for never to have to delete a private key. The need for private key deletion usually arises from people generating keys on their desktop system, to manage certificate enrollment from the comfort of their desk, and then transferring the private key and certificate to the system that will actually use it. This is poor practice, because it may leave traces of the private key on the desktop system.

Private key deletion is not very easy (as shown above: custom C program or undocumented command), and even when it works, it really is a file deletion, which does not actually ensure that the data no longer exists; file deletion merely marks the corresponding space as "free for reuse" but does not wipe it proactively.


Using "Security Compliance Manager" to audit a Windows system

SCM itself does not audit or apply settings. Settings are applied by importing a GPO backup in to AD and reported on by importing a DCM in to SCCM (no relation to SCM despite the similar abbreviation).

There is documentation that describes how it all works under "attachments" for each baseline.


Differences between Intel TXT and Linux IMA

No, they are complementary.

DRTM provides a Root of Trust on which you can build applications/use-cases such as Integrity measurement of your entire linux system (IMA). However, it is not part of it.

I think the simplest way to explain this is with the following:

IMA needs the kernel to evaluate the integrity of the system (e.g. userland);
DRTM (or SRTM for this matter) can validate the integrity of the kernel itself. See tboot.

I suggest reading this to have a feel for it - the "Value Proposition for Linux" more precisely.


Can I use an old version of IIS and still be secure?

According to wikipedia IIS 8.5 is included in Windows 8.1 and Windows Server 2012 R2 and both systems are still supported for some time. This way IIS 8.5 also receives updates and if you always update the server by itself will probably be secure enough until the end of support.

But, the main attack vector is usually not the web server itself (i.e. IIS) but the web application served by the web server or the database used by this web application. Thus if you run some insecure CMS (i.e. Wordpress without latest updates) or other insecure web application on your system it does not matter if IIS by itself is secure since it will not protect the insecure web application.


Can an identity provider impersonate me? (Can Facebook post Stack Overflow questions under my name?)

Yes, they can.

Simple answer: You authenticate in some way to your identity provider, usually via username and password. The bad admin can store the transmitted credentials and just re-use them. This attack does not depend on how the backend is implemented.

In general your password for the identity provider isn't used for authentication to third-party services at all, which means that your identity provider actually has your login keys (and you do not have them at all).

You could think of schemes which incorporate your password into the authentication process without storing it unencrypted afterwards, but in practice I do not know any such scheme.


Passwords are user facing data. If you have a "password" that is neither set nor used by a user, it's called a "key" or a "secret" (exact terminology varies by use). So you need to research key storage, not password storage.

There are two parts to securing a key:

Choose a cryptographically secure random key. Something like 128 bits from a CSPRNG will do nicely. You can base64 encode the key if you want to store it as text.
Encrypt, not hash, the key when it is not needed. Use something like AES 256 for encryption. This leads to a bit of a circular problem as you need to store that credential securely. The best place for that is in an HSM. If that's not possible, storing it somewhere will have to do. Just don't put it in the same database as the keys in case an attacker gets DB access.


Changing server side certificate during ongoing connection -> is it supported ? what are the effects on the existing connections?

The server certificate is only used during the TLS handshake. It is irrelevant for the remaining session and so there is no need to close a session when the certificate changes. In fact the client will not even notice that a certificate has changed (or if a certificate got revoked) unless a new TLS handshake is done, i.e. either when doing a new connection or when doing a renegotiation inside an existing connection.

But it might be that specific server implementations will close a session as a side effect when the certificate gets changed for technical reasons, for example because the process needs to be restarted.

And there are  client implementations which restrict certificate changes on renegotiation in order to deal with the triple handshake attack. Thus if the server changes the certificate and a renegotiation gets triggered (maybe because a client certificate need to be checked) then this can result with current Java implementations in server certificate change is restricted during renegotiation.


Can you serve up special content to an end-user based on IP or other identifiable data?

Yes, this is a common practice. There are many ways to identify a user. Here's a few.

user agent string in the request
browser fingerprinting (pantoclick
IP address (country, region, ISP, known VPN ranges, blacklists, etc.)
referrer header
cookies
previous history (look through your own logs to ID return traffic)
URL history harvesting
css fingerprinting

There's an almost endless way of identifying different users/clients. Serving different content is supported in pretty much every language/server.  It's the basis of dynamic web apps (facebook, Twitter, pretty much every interactive webpage)


Sending temp password when users first registered - is that good for anything?

The procedure you describe seems to be the conflation of two distinct procedures which apply to distinct contexts.

1. Registration for a targeted individual

There are some contexts in which the registration is for a specific individual, with a defined physical identity, and occurs in a process which does not allow the setting of a user-chosen password. An example is when you "register" someone who you met at some trade show, and who gave you his business card. You know his email address, but when registration takes place, the user is not there. In such a situation, you have to send him a way to initially log in to your system (with at least some level of authentication -- you do not want to create an account for everybody, just for that guy) so that he could complete the procedure by choosing his own password.

An initial password, sent by email, and which must be changed upon first usage (enforced by the application), is one way to cope with that context. Sending him a "unique registration link" which brings him to a page where he can choose his password is, from a security point of view, exactly the same thing.

This is a non-ideal situation, in that the initial credentials must travel unprotected. Forcing password change upon first usage is a mitigation measure: yes, an attacker could intercept the initial password / validation link, but then he would have to choose a password himself, and at least the intended user will notice the problem (by not receiving the email or not being able to log in).

2. Registration for "anybody"

Most deployed Web apps which use registration work in a different context. Consider a Web-based vendor of some goods (think Amazon). Here, you accept anybody as new user. You need to "register" users because you want users to be able to keep track of their commands, and they should not be able to see the commands of other people.

In such a context, the user is available during the initial registration: he initiated it, he is right behind his keyboard at that time, and he can type in his chosen password under the cover of HTTPS. The Web app can accept this kind of registration because it is not picky: by design, anybody is entitled to register.

You still need a "validation link" sent by email, but for a very distinct purpose: the validation link is used to make sure that the email address is genuine. An attacker intercepting that communication could fool you (i.e. register under an email address which he does not "own" -- although he can intercept emails sent to that address, so he really owns it, to some extent), but such an attacker would not attack the same thing than in the first context. In the first context, the attacker impersonates the user who is entitled to log in; in the second context, the attacker is entitled to log in anyway, but he succeeds in doing so while providing the email address of someone else.

Summary

Sending a one-time initial password through email is a good or bad thing, depending on what kind of registration you are running. For a classical Web-based account creation that anybody can do, this is bad. For registration of a specific individual, the enforcement of a password change from the initial password is good, because in that case you already had to sent it by email, which is a security hazard (you just had no choice, and you must mitigate risks).


The standard solution is to use SSL (HTTPS).

Please spend some time with the search tool on this site.  You will find these questions have all been answered on other questions, so you can find lots of good information.  For instance, a search on "Javascript encryption" will find a lot of information about the pitfalls of encrypting on the client-side in Javascript.

Make sure to learn about how to enable SSL sitewide; about HSTS; and about the secure flag on cookies.

In general, I recommend OWASP as an excellent resource with a lot of information about good practices for securing web services.


SSH version outdated - closing port enough?

“SSH version is outdated” is not necessarily a security problem. Their recommendation is to install the latest version, but there is no benefit in running the latest version unless you want the latest features. For security, what matters is that you have all the security fixes applied. Many distributions apply security fixes to the version they ship. For example, CentOS 6 still ships OpenSSH 5.3p1 and will be receiving security updates until 2020; CentOS 7, the current release, ships OpenSSH 6.6.1p1. Debian jessie ships OpenSSH 6.7p1 and will also be receiving security updates until 2020, while the latest release stretch ships OpenSSH7.4p1.

In general, you should not install packages outside your distribution for critical infrastructure components such as OpenSSH. If you do, make sure to subscribe to security bulletins and apply security updates as soon as possible. If you just install OpenSSH 7.5 now and forget about it later, you're significantly weakening your security.

If you get a report that only says “version is outdated” and doesn't even try to determine whether the proper security patches have been applied, it's a bad report.

Closing external SSH access on servers that don't need them is a good idea regardless. One machine where the security updates are falling behind, or one machine where a user's password or key have been compromised, could get the attacker into your network. It's often a good idea to limit external access to a single gateway machine (or a small set of machines for redundancy) where updates and account are more closely monitored. Closing the port in the firewall will mitigate the issue of direct access. Indirect access (where the attacker gets into the network on a machine that's doing nothing important, and uses that as a relay to get into more important machine) will still be a concern.

You can check SSH access by yourself by running ssh -v MACHINENAME from outside. If MACHINENAME is running an SSH server and the firewall doesn't block you, you'll see a line like

debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Debian-5+deb8u3

That, as I write, is the current version on Debian jessie and is perfectly fine.


Will "Authorization: Bearer" in request header fix CSRF attacks?

Would this approach actually work to prevent CSRF attacks?

Yes. An attacker can't  make a browser send a request that include the authorization header with the correct bearer token. This is for two reasons:

The attacker can't set the authroization header.
The attacker don't know the correct value of the token, so they wouldn't know what to set it to.

However, this might be sensitive to changes in your application. For instance, if someone one day decides to change the authentication system to something cookie based, they may not realize that they are disabling your CSRF protection by doing that.

Also, in the case where the required header value is predictable, a CORS policy that allows that header to be set could spell trouble.

As for the linked SO question, I am not sure I understand the accepted answer. But if you look at the second answer, your situation is of type #2 and not type #1.

  I know If I am vulnerable to XSS attacks my cookies can be read and the bearer tokens can be stolen. But can the injected XSS create a the Authorization: Bearer header and append the stolen value from cookie?

Yup, you could do that if you can inject code.

If you have an XSS vulnerability, it will allow the attacker to bypass any CSRF protection you put in place. So concerns for XSS can't really be used to favor one form of CSRF protection over another - in the face of XSS they are all void.

A slight difference here is that your token cannot be marked as HTTP-only, since you need to access it from JS to put it in the header. Consequently, an XSS attacker can steal it and then conveniently send requests from her own computer. If the authentication token is HTTP-only the attacker has to make the injected code send the requests, which is a bit of a hassle but not impossible.


Can an intruder still possibly succeed with pass-the-hash or pass-the-ticket on Windows 10 / Server 2016 networks where Credential Guard is enabled?

Against normal adversaries ( non-APT; e.g. cyber criminals) it will be quite effective.
But I'll focus on the question of how to bypass Credential Guard so you can get an idea of the sophistication needed.

In the link you provided Microsoft has a visual describing the various security rings of a system.

Like most people Microsoft put Hypervisor (ring -1) directly above the hardware.

Of course, it would undermine their point and raise questions if there was to be a layer between their security mechanism and the hardware.

  But if i google ring -2 i don't get any fancy graphics describing anything more privileged...

No. But you will get a mention of SMM here and there. This is usually not something that you can experiment with, so there's not much resources on it.

However this video and this slide deck describe exploits for "rings" that are lower than the Hypervisor and could circumvent the mechanism you mention:.

  ... we have encountered systems in the wild where the SMRAM is locked by a non-integrity
  measured BIOS, thereby preventing an SMI intercept from being generated when the CPU is in guest mode. In other
  words, an SMM handler (as a result of an SMI) can execute in SMM mode without the hypervisor having any control
  over it. This leaves a hypervisor on such hardware potentially vulnerable to malicious SMM handler code.

The NSA has developed multiple rootkits for this mode of operation.
From the wikipedia on SMM:

  By design, the operating system cannot override or disable the SMI. Due to this fact, it is a target for malicious rootkits to reside in,[12][13][14] including NSA's "implants"[15] which have individual code names for specific hardware, like SOUFFLETROUGH for Juniper Networks firewalls,[16] SCHOOLMONTANA for J-series routers of the same company,[17] DEITYBOUNCE for DELL,[18] or IRONCHEF for HP Proliant servers.[19]


Is it safe to rm -rf an untrusted directory?

Hard link to directories have been brought up in comments. Nominally they cannot happen; Unix-like systems have disallowed them for a long time because they would allow the creation of loops. Since space allocation in such a filesystem is based on reference counting, a file being really deallocated when the last link on it disappears, a directory loop could induce a bunch of inaccessible files that are not reclaimed.

However, being disallowed does not mean that it cannot be done; only that the purported disgruntled employee would have to fiddle with the disk structure, which would entail root or physical access (root access to do it remotely; if the employee had physical access then he could simply reboot on a live CD or USB to play with the disk). In the filesystem structure, sub-directories are referenced from the parent directory, and noticing a case of the same directory being referenced from two distinct parent directories would require, in all generality, a complete vision of the whole directory tree. The kernel does not try to maintain such a vision since it could potentially use up more RAM than available. Thus, if the directory structures are altered to include several links to the same directory, the live system won't notice it.

fsck detects loops, but it does so only when it runs, i.e. only at boot time, and then only once every N reboots, for some (configurable) value of N. It may detect some other cases of multiple links to the same directory (without making a cycle) but I cannot vouch on that, for the same reason as explained above: to reliable detect all cases of multiple links, the complete directory tree must fit in the RAM of the detection process. Loops are easily detected with a depth-first tree walk, but acyclic non-tree structure require more resources.

But, more generally, if the bad Joe had root or root-equivalent access, and is assumed to have potentially used it with nefarious intent, then the whole machine should be touched only with prongs, and only to push it to some industrial-grade shredder.

Symbolic links, on the other hand, do not cause harm here. rm won't follow symbolic links.

Evil Joe could have mounted another partition in a sub-directory of his own home directory, but, there again, it would require root access, and we are back to the previous paragraph.

In general, when an employee leaves the company, the process should involve a wiping/re-imaging of his workstation or laptop. If the employee is considered capable of mischief and assumed to have indulged in active sabotage, then deletion would not be the right thing to do anyway: you want to do some forensics and keep proofs.


While anything might be malicious, I see no reason to think it is anything other than what it claims to be: an inline image encoded with base64. This is part of the HTML spec and is done for a number of reasons, typically having to do with performance (although I'm dubious about the wisdom of using this technique on larger files).

Most likely your browser already decoded it to reveal a message in the form of a JPEG image. If you find this tag on the actual page I'm sure you will find your browser is displaying an image.


Double/Chained VPN - Which IP will be vissible to the VPN providers?

Yes, that's correct.

VPN B will see VPN A IP

VPN A will see your external IP.

Because the router will establish a connection to VPN , all packets forwarded by the router (so packets coming from his computer MAC) will be forwarded through VPN A. In order to be routable on the internet, the VPN provider will masquerade (NAT) all outgoing packets with his exit node IP. When MAC will try to reach VPN B, VPN B will see VPN A ip.

For the question :

  what happens if the VPN A was down and the VPN B sends a packet to the
  router?

It depends but if the 2 connections are established (VPN A & VPN B), and VPN A goes down, there is a high risk that your router external IP will be disclosed to VPN B. MAC will continue to send packets to VPN B and it will not be masqueraded by A as VPN A is down.

Your connection to VPN B will also have a chance to go down as for VPN B, your IP has changed. It's now receiving packets from your router IP and not from VPN A. If you want to be sure that you will never disclose your router IP, you will need to add firewall rules on your router.


Securely redirecting to a different domain with sensitive information

Since redirects must use GET instead of POST, how can I send the token without it being exposed in the url?

Redirects can actually use POST (redirect code 307) but since POST is considered a state-changing operation contrary to GET it should not just be repeated without asking the user. Best would be if it does not matter when the token gets visible, i.e. it can be encrypted by the origin site and decrypted by the target side. This can be done for example with public key cryptography if the origin knows the public key of the target.

  however I know  ... that SSL can be compromised if you don't verify the certificates on both ends of the request.

This statement is not true and it is not claimed in the question your reference. For securing a SSL connection against man in the middle attacks it is only needed that the server authenticates itself with a certificate and the client properly validates this. Client certificates are only needed if the server likes to authenticate the client but are not needed for protection against a man in the middle.

There is no special thing to watch out with redirects and HTTPS in your case: the client simply does TLS to both sites and validates their certificates.


Is OAuth always the right choice (and when isn't it)

The answer to the first part of the question is easy: no protocol is always the right choice.

OAuth solves (well, offers a solution to) a lot of little nagging problems like authorizing clients and protecting resources in a semi-granular way across browsers, active clients, and whatever is in between.

It can be overkill, which is a good reason not to use it. It doesn't do authentication (OpenID Connect is the authn extension to OAuth), and it doesn't offer certain behaviors that other protocols do, e.g. SAML, but on the other hand that might be a good thing.

The solution offered by Google has a lot of characteristics of OAuth, but relies heavily on the cookie, and doesn't look like it would scale well for public use. If you don't care about exposing the APIs publicly it might be fine, but if you ever want to then OAuth would be a better approach relative to that solution.

If you do go down the OAuth route you will likely want to support the latest version as that gives you access to OpenID Connect. Otherwise you're stuck building out your own means of authentication, and all clients will have to implement against your custom design.


What are the best practices to create a safe and performant user registration and validation with Nodejs and Postgres?

I want to post an answer here for future references.
This is mainly for developers who are developing hybrid apps, native apps (ios,Android) and Progressive web apps (PWA).
Most common technologies used with those types of apps (not exclusive) :

Cordova
Nodejs
Vue
React
Javascript
JSON
socket.io (websockets)

Most common databases used (not exclusive) :

Firebase
MongoDB
PostgreSQL (still RDBMS but offering support for json/jsonb)

When it comes to me Im using Nodejs, javascript for front-end,
storing JSON/JSONB in PostgreSQL and socket.io to listen for updates in my database which allows me to create real-time apps.

At first when I was asked to migrate our app to a more performant and efficient technology, I had no idea what to look for in terms of security but I knew I wanted something more

secure
efficient
performant
less error prone

Coming from a PHP/MYSQL background, I realized I had to unlearn a lot
of bad habits that I'm still unlearning at the moment.

Things I have to let go of to meet all above requirements :

password hashing : md5(), sha1(), hash()
username matching

But what's wrong with password hashing and username matching, you may ask?

The short answer : it's error prone, inefficient and very synchronous

The solutions
I found actually 2 solutions to creating more secure and efficient oAuth systems in your apps. Your login and registration systems don't have to be a pain to write.
 Solution #1 : JSON Web Tokens (OpenID Connect)
If you are already making heavy used of Javascript in your software, especially JSON and the technologies I've mentioned above, learning to work with JSON Web Tokens (JWT) is standard practice these days. JWT are also certified and follow the OpenID Connect protocols which means any app using JWT is compliant according to the oAuth 2.0.

JSON Web Tokens are an open, industry standard RFC 7519 method for
representing claims securely between two parties. JWT.IO allows you to
decode, verify and generate JWT.
Read more here

Benefits and advantages of tokens

create two factor authentication systems (email, username + tokens)
single sign-on systems
security compliant
standard usage of oAuth protocols

Disadvantage of tokens

learning curve

 Solution #2 : authentication-as-a-service
If you don't want to handle registration and login on your own for security issues, you can safely turn to a third party who will handle it in the background for you and all you have to do is connect your app using their API.

Authentication as a Service (AaaS) provides authentication services
like multi-factor authentication, single sign-on, and password
management in the cloud. With Authentication as a Service,
organizations can control access to their applications and servers
from various devices and networks.

There are several different AaaS around, but during my research, the one I found to be open source and free to an extent is auth0.

I'm not using auth0 services nor do I work with them nor am I
affiliated to them in any way. This is for education purposes only.

Benefits and advantages of AaaS

secure out-of-the box solution
human friendly with dashboard and user management
remote hosting
Easy API docs

Disadvantages of AaaS

must rely on third party service
Can be pricy in the long run (not exactly open source)

Open Source Projects
Great alternatives to expensive AaaS. The MAJOR plus is that they are self-hosted which means YOU own the data no third party.

GLUU Server
SuperTokens
NextAuth.js (React)
ORY.sh


Google Authenticator is pretty secure. Certainly better than nothing, and in fact better than most of the options out there.

Yubico OTP devices are slightly better, because it's more difficult to extract the keys out of a Yubico device than a cell phone.

That said, neither is perfect because both are OTP-based and therefore both can be phished. This is a vulnerability that is today being actively exploited by groups like the Syrian Electronic Army, and is the cause for a number of high-profile breaches.

There is a solution which can't be phished, but as of this writing, LastPass doesn't support it. So while I still recommend using your Yubikey or Authenticator code as a second factor, I would caution you to not let your guard down in its use, because you're still vulnerable to phishing.


As the base password and my very strong password are both stored in Lastpass do I actually gain anything from using 2fa with Fastmail?

The answer to this "most probably yes".

There is two ways you may gain some security this way:

In case someone manages to steal your service password (for instance through code injected in your mail client or web browser), you will prevent them from reusing your password at a later time because the OTP generated by the hardware key will not be valid any more.
Inherently, your password will be "longer" if you add the OTP than if you don't.

However, the real question you should ask yourself is: "Is the additional security worth the additional hassle?" That's a very personal question and no one can answer it but you.

Additionally: I suggest you take a moment to consider how you can regain access to your account in case you lose your key (or access to your password database). This is actually a more important question because, if you're a typical user, that is a risk that is far more likely to materialize than having an account with a strong password being compromised in a way that would have been prevented by adding a hardware token.


Can a USB with an infected MBR or GPT harm an OS that reads it?

For classical boot-sector viruses, generally no.  Those require execution of actual code embedded in the boot sector (which happens to coincide with the partition table in MBR arrangements, but not in GPT configurations), and no sane OS executes code from the boot sector of removable media.

There is at least one notable exception to this though, the Amiga Rigid Disk Block (RDB) partition table format can embed filesystem drivers in the partition table itself, so it is theoretically possible for malware to be spread that way, though it's extremely unlikely (it would only work on systems running AmigaOS or compatible operating systems, and the market for such malware is nearly nonexistent).

There's a relatively small but still present chance however that the OS itself may have a bug in the parsing of the partition table that would eventually allow for an ACE exploit that could be used to infect the system.  For an MBR, this is extremely unlikely, the format has been around for decades, is a fixed size, and is trivial to parse.  For GPT, it's a bit more likely, as the GPT structure is variably sized (though it's rare to see one that isn't the standard 128 entries).  Other partition table formats would have varying probabilities, but probably don't matter much anymore today.


Use OpenId Connect for authentication only

Looks like I found the answer on Access Token:

  UserInfo Endpoint

  It should be noted that clients are not required to use the access
  token, since the ID Token contains all the necessary information for
  processing the authentication event. However, in order to provide
  compatibility with OAuth and match the general tendency for
  authorizing identity and other API access in parallel, OpenID Connect
  always issues the ID token along side an OAuth access token.

http://oauth.net/articles/authentication/


Danger in opening spam emails on Ubuntu operating system

A virus or any other form of malicious email may "harm your data" only by exploiting a vulnerability in the overall system, leading to execution of attacker-controlled instructions.

The "overall system" includes both the user's computer, and the user himself. In a phishing attempt, the primary vulnerability is the meat bag: the email contents induce the human user to take actions which are in accordance with the pursuance of the attacker's goal but ultimately detrimental to the user himself. This is not new and such attacks have far preceded the invention of computers. However, a recent twist is the realization that many users seem to lose their common sense when dealing with a computer, making them easy targets for con-artists.

Linux-based operating systems, generally speaking, have proven less vulnerable to malicious code in emails than Windows, for several reasons:

The Unix ancestry of Linux has promoted a rather strict philosophy of secure data handling, which might help prevent really dumb things such as automatically running incoming executable files.
The Linux ecosystem is very varied, both for OS particulars (emplacement of binaries, versions of libraries...) and for email applications, making exploits less universal.
Linux's share on the desktop market OS being what it is (1.29%, according to StatCounter), most attackers don't deem it worth the effort. Attackers are no less lazy than anyone else, and prefer to concentrate on the about 85% of Windows, which are much more likely to result in profits for them.

However, remember that the OS and its applicative software can only have limited success at fixing vulnerabilities in the human side of the system. Software can try to avoid "dangerous" situations in which humans have been known to take really wrong decisions with alarmingly high probability, but ultimately the user MUST demonstrate a less-than-absolute gullibility. Otherwise there is no possible security.

Therefore, malicious emails harming your data are improbable (but at least theoretically possible) if you use Linux and if, as a human user, you do not do anything foolish.


Can you defeat evil twins using public and private keys?

If you configure wireless access points for mutual authentication, regular users will not automatically connect to unknown networks.

The easiest way these days is probably EAP-TLS (basically everyone supports it). Note that the user's machine must trust the certificate from the access point, so a one-time setup will be necessary which places your CA certs into their OS trusted store. Obviously, this only works in enterprise scenarios where you've deployed certificates to network devices.

For open public wifi, there is no solution. As MTG mentioned, you simply use TLS to secure your communication. The network will be able to see where the packets are going, but your data will remain confidential.


What's a least-privilege way to allow node.js to access network adapters on Linux?

Based on a recipe by Jeremy Stretch from Packetlife:

Ingredients

setcap (usually comes with the libpcap2-bin package) - it will allow you to set the special kernel permission/capabilities that node needs when running as a regular user account.

Cooking

A. Give node capture capabilities:

setcap 'cap_net_raw,cap_net_admin=eip' /usr/loca/bin/node

B. Report on success.

C. ???

D. Profit.

Hope this helps!


You are mentionning two Privacy issues here: Circumvention of censorship & password protection.

When it comes to government firewalls, it is wise to use widely spread softwares, as they have been tested a lot and are known to work as safely as you can find. The reference here is Tor and is used daily by insurgents in countries famous for their restricted internet access like Syria or China.

For your password privacy, this is not a topic I am very knowledgeable in, but I would advise you to not use any extension on your browser when typing a password. I would not even trust the browser itself. If whatever you are doing is highly sensitive, I would suggest using Tails that comes bundled with… Tor!

For your specific application (Browsec), there are several signs that you shouldn't trust it:

it is closed source (debatable, but you don't know what happens behind)
has very little review online (drawbacks of not being famous)
says they collect your data and may transmit it to a government
state that the traffic goes through their network, hence any access to an unencrypted website, they can read it all. possibly SSL protected ones aswell depending on implementation.


What kind of answer is this textbook question looking for in access control model?

So to summarize:

Group 1 contains S1 and S3
Group 2 contains S3

Then it is pretty simple, if you know that in Linux, the 9-character permission scheme can be divided as follows:

First three characters are the owner's permissions
Next three characters are the group's permissions
Last three characters are the permissions of all of the other users

Then, following the assumption I made, you know the following:

Permissions    a     b    c
S1             rwx   -    rwx (S1 is member of group 1: group 1 has rwx permission)
S2             rwx   rwx  - (due to explicit owner deny on the last row of the table)
S3             rwx   -    rwx (due to group inherited allow permission of group 1)


How to protect a PC against sensitive data access by malicious app/driver

A driver, by definition, is part of the operating system. As such, whenever someone is able to place a malicious driver, it gets access at a system level of privileges. That means it can access every single bit of memory your computer has.

You lost the game.

The only way to effectively counter this are air-gap security. Ie. place your machine in a room without any link to the outside (and that would include unintentional RF radiation, eg by rhythmically bursting a PCIe bus, or by actually RF transmitting malicious hardware), and monitor personally who accesses the computer.

I'd love to say something uplifting about not having the driver installed in the hypervising operating system, but in a lesser privileged VM – but the reality is that you probably want to use the device in the same context that you're developing in (otherwise, you'd simply not install the device in a sensitive environment, at all), so that basically simply doesn't help.

Note that the problem doesn't stop at the software level – if your hardware is a PCIe, CardBus, PCI, AGP, PCMCIA, ISA, PXI, PCI-X, FireWire, Thunderbolt, or one of many storage device classes (Floppy, IDE, probably a lot of Sata devices, M.2,), typical "tightly coupled" buses like HyperTransport, AHB then it might get DMA – and thus, exactly that, Direct Memory Access, without any chance of the Operating system, an antivirus software or even just the CPU to interfere. Usages of this mechanism to read out, and exfiltrate, the contents of a PC's complete RAM have been demonstrated numerous times.

You use the USB tag, but you don't explain it in your question – USB itself doesn't give the devices DMA capabilities, but many USB host chipsets and device drivers actually have bugs that allow USB devices to essentially get memory access. Note that this leaves the "malicious driver" domain, and enters the "buggy host-integrated hardware" and "buggy driver" domain – and everyone having ever read a piece of consumer windows driver will agree that this class of drivers is the dominant one.

All in all, installing malicious hardware in your machines is pretty much the "evil maid" scenario, only that you are the evil maid yourself.


How can I best protect myself on an encrypted network with untrustworthy users?

Buy your own hotspot from a provider for your laptop.

Using university wifi gives them the right to monitor what you do and say on the web. As you pointed out, it also exposes you to potential bad actors.


how to get sites original ssl cert when using company firewall that returns its own ssl cert

No.

The firewall configuration you are describing does a SSL MITM. The certificate at the source website is processed by the proxying device, then discarded, it doesn't reach your own computer. This means you can't see the certificate that was provided to the proxy. You need to trust that it was the right one and it was validated correctly (in some cases, it would not validate them properly, leading to the final users being less secure).

That's the reason Extended Validation, HSTS, etc. are disabled by that configuration with a local MITM. You can't know which certificate was presented. In fact, note it may not even have been an original certificate (e.g. the page you are shown is an interstitial).

If you need to inspect the site certificate, you will need not to connect through the MITM firewall (getting an exception, connecting through a VPN, etc.).


How dangerous are reverse-shells to a network?

In an ideal world, no computer should ever have a vulnerability, right?
 Unfortunately, we don't live in such a dreamworld, and when vulnerabilities are exploited, the payload is often a shell of some kind.

Even the most restrictive networks often allow DNS queries to be sent and responses received; this is sufficient to host a reverse shell, but not a forward shell.

Sometimes it's only a matter of time. Many a nasty surprise has been had as a result of the underprivileged breaking out of their confines with privilege escalation vulnerabilities, local buffer overflows, etc, and if you have a shell running as an underprivileged user on a system at the right time, that's your foot in the door. Underprivileged access is good for the patient "hacker"; he/she can just bide time waiting for a vulnerability to come along...

... and then what better tool to keep access to the system when administrative access is obtained? It just needs to be added to startup registry, as a system service, crontab or many other places...

That aside, not every vulnerability needs to result in root access. I recall once upon a time when I'd written a C program to serve a few static images. Now you'd think that such a program shouldn't contain a buffer overflow, and I was fairly confident, but it did. It did, and it was exploited. It might've been isolated from the rest of the system, but that didn't stop the "hacker" from running nmap to scan subranges on my system.

Perhaps if I'd had a network-enabled printer on my network, or a vulnerable router, they could've used the underprivileged account to gain access to other systems! At that point, again, such a hacker could bide their time, occasionally testing the entire internal network for vulnerabilities in the future and waiting for administrative access, if the intercepted traffic and documents aren't lucrative enough...

This also reminds me of an era when IRC was a disgusting quagmire of infectious filth. Spam would be in the form of commands which some users would type, and then their systems would be used for further spam, of course. This is still no doubt the fate of many compromised machines, since forging unsolicited bulk email doesn't require administrative tools and may provide a financial incentive.

While we're on the topic of financial incentives, have you been following the price of ether?


Here are some C/C++ examples:

Reading a long into an int memory space (say with scanf).

int i;
scanf("%ld", &i);

Using a float as an index in a for loop instead of a fixed point structure, resulting in possibly one more or less iteration than expected.

char *arr = new char[9];
for(float j=1; j>0; j=j-0.1) { // will clobber 10 characters, not 9
    *arr++ = 'A';

copying between arrays with different type widths

float floatArr[10] = { 5, 5, 5, 5, 5, 5, 5, 5, 5, 5 };
char charArr[10];
memcpy(charArr, floatArr, sizeof(float));


What are the alternative to PKI certificates in mesh networks?

Machine A wants to talk to machine B "securely": it wants to be sure that it talks to the right "machine B". If it can do that, then it can do Diffie-Hellman with B and then use the key with the usual crypto tools. But all of this works or is even defined properly only if there is a way by which "machine B" is, from the point of view of A, distinct from any other machine (e.g. C). Without prior knowledge, "B" is just a name and any other machine can logically claim to be "B".

In other words, you need to have a central point somewhere (not necessarily as a physical system; it could be a central concept) which defines that there is a single machine called B, and pinpoints that machine among all others. With an authentication server (your RADIUS example), the central point is indeed a machine which all others trust, and use. With a PKI, the central point is administrative; it is whatever mechanism is able to give a name to each machine, and prevents two machines from claiming the same name.

Certificates are ways to transfer trust. A certificate binds a name to a public key; from the point of view of A, if a certificate has been signed by D and contains the name E and a public key, and A knows D's public key, and A trusts D for not goofing up, then A verifies the signature on the certificate and thus gains some knowledge on E's public key. The certificate is an assertion from the certificate issuer (D) about the binding between a name (E) and a public key.

There are mostly two ways to do PKI:

the hierarchical PKI, à la X.509;
the decentralized PKI, à la Web of Trust.

The two ways illustrate two faces of a trade-off. The tricky point is what I wrote above about "goofing up". A WoT, initially, looks like a good idea: machine A initially trusts its own key. Then it may know from some out-of-band mechanism (A met D in a bar) the public keys of a few other machines, that it trusts. Then A may know the public keys of other systems (e.g. E) on virtue of their keys being signed by D, and the process extends recursively. This is decentralized and works as long as A can find at least one chain of certificates from itself to its ultimate target B; this process can be helped with public key servers, which are just repositories for certificates. The beauty of the thing is that there is no need for additional protection: a certificate is valid if its signature matches, regardless of how the certificate has been obtained. Public key servers need not be trusted in any way.

The inherent problem with WoT is trust dilution. That A knows D's public key does not mean that A _trusts_ D for correctly binding names with keys. At least A met D "in person" and could have some idea about D's gullibility. But A does not know E at all; A only knows what D says in the certificate that D signs for E. Thus, A knows E's public key, but not E's trustworthiness.

Hierarchical PKI manage the trust business by using specialists: certificates are issued only by authorized entities (the Certification Authorities); there are few of them, and they ultimately respond to a central Root CA which is like God for these things. This is very centralized, and this keeps CA in line and allows trust not to be as diluted as in the case of the WoT.

So this hierarchical/WoT choice highlights the trade-off between trying to do some decentralization (that's the point of mesh networks), and avoiding trust dilution. Choose your poison. The theory of WoT is that you can counter dilution by making the graph superconnected: if A finds dozens of certificate chains which all point to B with the same key, and all these chains go through distinct nodes, then B's alleged key is probably genuine.

At least there are useful mitigations. For instance, memory. A given node can remember the public key of another node. That's how it is done with SSH. The very first connection from A to B still requires something to ensure that A uses the right key from B, but afterwards it can just reuse it.

To a large extent, the notary model, as illustrated by Convergence, is a cross between offloaded memory (the notaries remember public keys and complain loudly when a node appears to change its key too often) and a WoT-like trust (when several notaries assert the same key for a given node, it is probably genuine).

In any case, the naming must occur somewhere. It can be a decentralized "somewhere" as in the WoT (a machine B can be "B" if it convinces enough other machines that its name is "B") or something centralized as the X.509 PKI (the central authority gives a name to each machine and there is no discussing it). But it must happen at some physical or conceptual level. Otherwise the question is ill-defined.


Does glibc2 version of the crypt function still use DES for alternative hashing methods?

I think they really mean hashing method for the hash in use. The format is:

  "$id$salt$hashed", where "$id" is the algorithm used (On GNU/Linux, "$1$" stands for MD5, "$2a$" is Blowfish, "$5$" is SHA-256 and "$6$" is SHA-512 ...)

the source of which is available on wikipedia.

I've just looked at the manual and it does indeed say "encryption method". These are definitely not encryption methods like DES, but rather "one way" hash functions.


How does Tor collect addresses of nodes?

Your Tor software comes with a list of predefined directory authorities. These authorities maintain signed lists of relays from which your client can choose to build the connection. A new relay publishes a server descriptor to the authorities to advertise itself.

Since not every Tor client acts as a relay, the number is smaller than you might assume and you don't need to somehow aggregate the node list yourself.

The FAQ explains this pretty well:

  Coordination: How do clients know what the relays are, and how do they
  know that they have the right keys for them? Each relay has a
  long-term public signing key called the "identity key". Each directory
  authority additionally has a "directory signing key". The directory
  authorities provide a signed list of all the known relays, and in that
  list are a set of certificates from each relay (self-signed by their
  identity key) specifying their keys, locations, exit policies, and so
  on. So unless the adversary can control a majority of the directory
  authorities (as of 2012 there are 8 directory authorities), he can't
  trick the Tor client into using other Tor relays.

You can explore the bridges and relays at Atlas or Globe.


The way that Hydra determines if an attempt was successful or not is by comparing strings found in successful and unsuccessful return pages.

in your scenario i am assuming that the application is returning Fail if the attempt is not successful and something else if it is. if the page is blank in both cases that means all the attempts will be considered successful.

you should find a unique string in the return page (or page source) and put it after the :

more information here

http://insidetrust.blogspot.com/2011/08/using-hydra-to-dictionary-attack-web.html


Criteria for Selecting an online PGP Generator

The correct line of reasoning is DON'T. There are simply too many issues.

It could generate it using JavaScript and not send it to the server, but the JavaScript is sent by the server, and so could change at any time (and even for specific targeted users).

It could generate it using a good CSPRNG, but again, this can be changed to use a backdoored or weak PRNG at any time for any or all users. In this case there wouldn't be any network requests for you to notice, but your key would be easily breakable.

It could be using a CSPRNG seeded by the system, but it could at any time be changed to use a CSPRNG seeded with a random value known to the malicious website, in which case the key won't be weak but it will be known to the website anyway.

Only generate keys with software that you trust. Since JavaScript is sent by the website every time you visit it, you have to trust that the website was not compromised, is not malicious, and that the developers and maintainers are competent every time you visit it. It would be preferable to generate keys with a signed release of well known and widely trusted software such as GPG.


Does the random presence of a common password sequence within a larger password weaken the password?

If you're picking uppercase and lowercase letters uniformly at random, that's log2(52) = 5.7 bits per character, so 5.7 × 8 = 45.6 bits for an 8-character password. And the answer to the worry that you have a 2-45.6 chance of randomly choosing password (one in thirty-something trillion) is that you probably shouldn't worry too much that you have about a one in thirty-something trillion chance of picking password.
More generally, yes, there is a probability that random selection will, by chance, pick the very first password an attacker is likely to try, or the second, or the third, and so on. As long as we make that probability acceptably low this isn't something to worry about.
There's seven billion people in this planet, which is about 233. If each of them has a thousand passwords each—about 210—that's 233 × 210 = 243 passwords, and if they all do 8-char passwords from a 52 letter alphabet (45.6 bits) that'd mean there's something between a 1/4 and 1/8 chance that somebody will pick password at least once. That might be a reasonable argument against recommending 8 upper/lower letter passwords to humanity at large, but only because it's modestly likely one lone person in the whole wide world might be bit by one of a thousand random passwords they choose. (Well, actually it gets a bit worse once you consider longer password cracking dictionaries.)
8 upper/lower letters is cutting it much too close, though, because of computing power.


How does this HTML5-based "Mass Router Infection" scheme work?

These types of attack could be achieved via multiple CSRF attacks against the IP addresses discovered via the JavaScript reconnaissance tool.

Say your local IP address is 192.168.1.100. You visit the malicious website, the JavaScript runs and finds the device 192.168.1.254 on your network. Now, depending on how complex the JavaScript is, it will either identify the router make and model, or will just try a brute force attack in order to exploit the router.
That is, it will send every exploit in its database at the device in order to try and compromise it.

Say that the BOB 2000 router has a vulnerability in that its URL /config/remoteConfigSettings does not implement any sort of authentication checks. As this page is only accessible from your local network, it is not normally vulnerable to internet based attacks.

However, after someone on your network has visited the malicious site, this could try every attack in its database to try and exploit the router at 192.168.1.254, including sending a POST request from the browser with the message body:

AllowInternetAccess=true&RequirePassword=false

to http://192.168.1.254/config/remoteConfigSettings.

As this page is vulnerable, the request causes the WAN side of the router to be available for remote administration and disables the password authentication. The malicious website can report that a device was found to the attacker along with the internet IP for the attacker to log into later either manually, or more likely to add to an IP list for automated exploitation now that remote access is granted. The remote exploitation could include anything from altering DNS settings to an attacker controlled server for a future MITM attack, to malicious firmware updates to the router itself.

As well as checking for known vulnerabilities, the malicious script could also try regular router requests but authenticating with default or commonly used credentials.

Update

Regarding @Ajedi32's comment about the Same Origin Policy - the scanner does not need the router to be in the same origin in order to fingerprint it. It uses a combination of IFrames and image tags to determine whether something and what was loaded and then matches these against known default IPs. From the author's site:

  The scanner accesses a IFrame to perform a generic scan of the network
  for known default router IP’s, once a connection has been made it then
  passes the IP address and performs a lookup of routers/devices based
  on that address. The reason I have decided to do this is because I
  wanted the scanner to grab as many devices as possible because it will
  be impossible to finger print everything.

  Once a IP address has been found it passes this to the finger printing
  function which uses a image object to make a connection to the device
  to see if the finger printing graphic is there.

Via DNS Rebinding

Another possibility not discussed in the linked article is a DNS Rebinding attack. Say the IFrame trick detects something is running on 192.168.1.254 once the victim has visited evil.example.com. The attacker's detection script then runs a server-side script to rebind the DNS of evil.example.com to 192.168.1.254. As the DNS entry has a very short TTL, the browser requeries the name lookup and gets the router address. As the router has default credentials setup, the malicious page can send AJAX requests to read and alter any content on the router's configuration page. This "bypasses" the same origin policy as the router now has the same origin as the malicious site (http://evil.example.com:80).

This attack would count on the browser timely rechecking DNS. Most browsers have their own DNS cache outside of the Operating System's, and may cache for longer than TTL dictates, hindering this type of attack.


Why are network scans coming from my router?

If it's coming from your router, then your router's been compromised, no question about that. Someone is tunneling through it.

Simply resetting the IP isn't enough. You should do a factory reset of the device,  reset the password, and report the incident to the ISP.


How can I be sure that I am using the real Facebook?

You can confirm that you're on the real Facebook by a variety of ways:

Inspect the certificate used to secure the site. Open up your certificate (instructions vary by browser) and see what it says - is it issued to Facebook? Is it in a valid time period? Now, look at who signed that certificate, again, turn a critical eye towards it. Make sure everything makes sense. Go down the certificate chain until you get to the root certificate. Now, go to your favorite search engine and check that none of the certificate vendors have been in the news for a compromised private key. Unfortunately, the CA based ecosystem means you have to just trust the root CA, to some degree.
Check the IP address you're connecting to - use your favorite NSLookup tool to see where your DNS is pointing you when you connect to facebook.com. Take that address to google, see if it matches what people commonly say Facebook's public IP address is.
See if other people have recently reported issues connecting to Facebook over TLS, or have any concerns. Consider if those concerns seem valid to you, or if they seem like the user is just doing something incorrectly.

Next, take all the data you've gathered from the above points, and any other reconnaissance you've done. Think critically about whether you think it's reasonable that all of the above has been faked by a convincing virus, evil malicious actor on your network, or Mark Zuckerberg having a laugh. Also consider that the issue you want to avoid (submitting or viewing information from Fakebook rather than Facebook) and think if it's possible that the eventual consequences (data leak) could happen in another way, such as a screengrabber or keylogger virus running and just recording your input into the real Facebook. Then, consider if the risk outweights the value you'd gain from logging into Facebook. Then realize that Facebook gives you no value and decide it's not worth the risk.


Does Speculative Store Bypass Attack Require Assembly/Source Code Knowledge?

Yes, the attacker must know something about the program being attacked.  All the attacker can observe is how often cache lanes get evicted.  They need something else to tell them what those evictions mean.

The power of the attack is that, in the vast majority of cases (I'd say at least 99.99% of the time), it is far easier to get the code of the program being attacked than it is to get the information which is being protected by that code via normal means.  The only exception I can think of would be software which was developed on an air-gapped network which is never released outside of that network.  That kind of software could be difficult to attack with this.


Are images created with commercial software stamped with identifiers that can be traced back to a serial number?

This would be difficult to conceal, for a number of reasons:

Most image formats used these days have well-documented formats, and are interchanged between different companies' software, so extra fields would be difficult to conceal
Lossless formats (e.g. PNG, GIF) would by definition not allow such modification; in practice it could be done, but it's likely users would notice
Lossy formats would allow such seganography, but there are likely too many formats and too many software companies for there to be any concerted effort that has yet to be publicized.

On a separate note, many (most? all?) manufacturers of color printers DO print almost-invisible pattern of yellow dots on each output page, encoding information about the printer, probably as an anti-counterfeiting tracing device


What to do when I found a spyware that my spouse has installed?

Normally, I'd just parrot the "nuke it from orbit and start from the beginning" line. However, information security is also about understanding your adversary, the practical risk, and the assets you're trying to protect.

In this case, I think situation is a bit different; your spouse clearly just Googled for "free key logger" and downloaded the first one or two results. You're not dealing with some skilled attacker trying to hide rootkits or compromise your BIOS.

I've just looked into this Spyrix application and it seems that if it's not password-protected, you can simply click "Stop" (which, according to the screenshot, you've already done) and then uninstall it normally. You don't need to remove your operating system or flash your BIOS or anything of that sort. You don't even need any special "removal tools" in this case.

Having that said, if you still feel you're not satisfied with the integrity of your system (I generally wouldn't), then just remove it and install it again.

Side note: I really don't think your problem is technical. Go talk to your spouse as there are deeper reasons behind this. Almost everything can be fixed with an honest and calm conversation.


How is AMP-Same-Origin: true even remotely secure?

It adds security for "simple" CORS requests that would otherwise not require an OPTIONS intermediate request. By requiring the AMP-Same-Origin when the Origin header is not set, you can fail all requests that would otherwise cause side effects, even if they weren't viewable at the endpoint, because they would not fail until they came back to the browser

It is not possible to add the AMP-Same-Origin header on a cross origin request if CORS isn't explicitly allowed. Thus, you do not need to add a random string like you usually would with a csrf token. Check this related question about it

Simply checking the value is sufficient at the moment, but future
technologies and attacks may be leveraged to break your protection.

Simply checking for a custom header is sufficient for now. However, this is not the best practice and for additional defense in depth it is normally recommanded to have additional security in depth as per MDN

To prevent cross-origin writes, check an unguessable token in the
request — known as a Cross-Site Request Forgery (CSRF) token. You must
prevent cross-origin reads of pages that require this token.

You could also ask yourself (or not if you're already aware of it), why don't they just set the Origin header instead of setting an additional header ? Well, the Origin header is a forbidden header and cannot be set programmatically (MDN).