How is IRC so secure/untraceable that hackers and pirates use it to communicate?

In addition to Rory's points...

Internet Relay Chat is actually incredibly insecure

I don't think IRC is in any way secure by default. Almost all servers utilize communication through plaintext. Your ISP can snoop on the contents easily. All of your messages, in general, are unencrypted. You have to install addons to enable encrypted communications, if they're even done right.

Even if the server itself encrypted the messages/uses SSL, it's a moot point: everyone can connect and read what you're saying unless you encrypted it on your end. IRC admins can read your private messages as well.

The vast majority of servers I've visited also expose your IP Address to everyone unless you're behind a proxy or VPN, so there's no real anonymity. Even the ones that partially mask your IP will show part of where you are. For example: Random432342.hsd1.ca.comcast.net. While other servers will block everything, all IRCops/admins know the real IP you're connecting from. What's to stop them from cooperating with law enforcement?

Your IRC client could also be vulnerable to buffer overflow attacks / string formatting vulnerabilities / etc. Or maybe you'll just click on a drive-by-download link...

Does true anonymity exist on IRC?

Some people have a different definition of anonymity than me. Rory's definition is correct in the context of being anonymous to most people, but that's not the definition I subscribe to. For me, anonymity is being anonymous to everyone, no matter what.

How do you think people keep getting busted even though they're "behind 7 proxies"? If you're behind a proxy/vpn, you're still communicating with the IRC server. Your proxy/VPN is connected to that IRC server, and you are connected to that proxy/vpn server at a specific time.

Once you send text, whether it's encrypted or not, all law enforcement really needs to do is line up timestamps, even if it's encrypted. Lag delay? Yeah, that's very easy to account for. Soon, a very clear pattern will emerge, and your entire proxy/VPN chain will be quickly unraveled to the source.

How can they do that? XKeyscore, Prism.

Right now, true anonymity doesn't really exist on IRC.

But Mark Buffalo, I've never been caught!

They either don't care about you because you're a small fry who doesn't matter, or they're slowly building up a case to get you on maximum charges. Or you're simply out of their jurisdiction, but they're still ready to pounce.

Maybe this "security" is actually a jurisdiction issue?

I think part of the confusion here is jurisdiction. Jurisdiction can offer tremendous security if there's a refusal to co-operate. This is why many criminals may still be around after "getting caught."

If you're in another country which refuses to cooperate with the law enforcement of another country, you might be safe from prosecution, but you'll probably still be indicted on charges. So as long as you never enter that country...


Can Windows 10 bootable USB drive get infected while trying to reinstall Windows?

Of course it can.

Either the OS created on the USB can be made out of a source that has been altered by the virus, either the virus alters the download if the USB stick is initialised with an image downloaded at the moment of the installation.

Even thought malwares usually have a specific task, a very good malwares could also alter the files that are copied when creating a USB stick or the ISO once downloaded


When did we start to call malicious software "malware"?

According to dictionary.com this was first recorded in 1990-95; mal(icious) + -ware

Following chart from google Ngram may help too, (Ref)


Javascript Malware: How does it work, and how can it be mitigated?

Drive-by downloads are typical malware vectors for JavaScript to get binaries onto a user's machine.  The JS just starts a request of a malware binary that responds with Content-disposition:attachment which prompts the user to download it.
The JS can continue this even if the user cancels, effectively making the user's browser unusable (they may not know how to kill a process manually) and often attempts to make the download look like antivirus software.
Some proportion of users will accept the download just to get their browser back, and then the malware vendor just has to wait for the binary to be run.

The core problem with viruses and malware is that the OS confuses the current user with the programs they run.  When I run Solitaire, that process has the ability to edit every file that I can from the command line or Windowing system.  That should not be the case.
There's no reason why Solitaire or a screensaver that you download from the web needs access to your tax files, so you can use a combination of cues to figure out what privileges it needs

Did the user grant authority via a file dialog or some other OS-mediated designation method like drag-n-drop?  ("Secure Interaction Design") explains a variety of ways to infer grants of authority by looking at the way they interact with a user-interface.
Is the file in a directory "owned" by the application by virtue of being created during the installation of the application binary?
Is the file a common system resource like a DLL or shared library?

Other privileges can be similarly granted based on user designation or simple rules.
Most operating systems and applications were not written with this in mind, so systems like Polaris from HP labs shows how to allow apps to run with less than current-user permissions on Windows.

People often forget that POLA means two things at the same time. Not only must you prevent the application from having more authority than it needs to do the user's job, but also you must ensure that the application has enough authority to do that user's job. Granting too much authority is why there are viruses that hijack applications. Granting too little authority means that the application is useless, like a spreadsheet program in a web browser sandbox that cannot save the result on your hard disk. Polaris gives neither too much nor too little authority: while a polarised application cannot in general corrupt or infect files on your computer, the application can indeed store information to any file that the user explicitly specifies by either double-clicking on the file or by selecting the file in a dialog box. Thus, the Polaris system dynamically adjusts the authority of the application to do what the user wants.
Unlike static sandboxes, Polaris does not appreciably affect the user experience. In fact, one HP executive used a pre-Alpha version of Polaris for three days without knowing it was on his machine. Polaris does its magic without changing applications or the operating system. Nor does it rely on intercepting system calls. Instead, when users "Polarize" an application, the "Polarizer" creates a restricted user account for that application. When users launch the application, either explicitly via the shortcut the Polarizer created or implicitly by opening a file of the appropriate type, Polaris uses a variant of the Windows runAs facility to open the program in its account. The bulk of the Polaris software hides this fact from the user.


Are there faux/fake malicious websites to test web reputation services similar to EICAR?

Unfortunately Google Safe Browsing doesn't recognize "malware.wicar.org" of http://wicar.org/ as a malicious site.  Instead you can use http://www.ianfette.org/ which is, I guess, the Google Safe Browsing test site.

Just in case you are wondering, Ian Fette is a software engineer at Google.


The Netgear AC1450 router is capable of logging exactly the information you want. This has nothing to do with SSL/TLS, browser incognito modes, etc. Just have a look at the manual, p. 80.


How do I identify which PC made a suspicious DNS query?

DNS request logging on your local DNS forwarder (Domain Controllers) is the easiest.  Blocking TCP/UDP port 53 outbound except for your Domain Controllers lets you be assured that only they can do recursive DNS lookups.

Netflow is another option, but has large data storage requirements since you are storing lifecycle and endpoint information about all UDP and TCP sessions in your network.

For effective NSM (Network Security Monitoring) you should have both DNS logging and Netflow enabled and it's worth getting both in place well ahead as logging that isn't a matter of standars practice will be disregarded as hearsay in court proceedings.  You can't just turn these on, gather stuff, use it as evidence, and turn them off again.


The problem you've identified is not specific to Arduino hardware.

It's a more fundamental issue: many reprogrammable USB devices can be programmed to identify as a USB HID keyboard/mouse, allowing them to control your computer when plugged in. Almost all Arduino boards fall into this category -- but many other devices do as well, including many that you wouldn't think of as reprogrammable.

(One exception is the Arduino Nano, which uses a FT232RL USB/serial chip which can only function as a serial interface. All other Arduino boards currently in production either use an ATmega32U4 directly, or use an ATmega8U2/16U2 as a serial interface.)

Don't plug USB devices into your computer which you don't trust.


pass the hash via psexec from windows server 2012 ( DC ) to client

The command is being run in a shell under an account that has administrative privileges to 192.168.1.22. This allows you to run PSExec on that device without the password, because the shell session is already authenticated. It's like how when you're already authenticated to Google, you don't need to login again to access youtube because of cookies.

This is also how token hijacking works. By hijacking an existing privileged process, no password or username is needed, similar to stealing cookies. Thus, using this method, 2FA is bypassed completely.


The answers to your questions are all in the PKCS #12 specification. I am going to take as reference the recent RFC 7292, which corresponds to "PKCS #12: Personal Information Exchange Syntax v1.1".

It is important to note that the private key is not derived from the password. What is derived from the password is the symmetric key that protects the PKCS12 object, which is completely unrelated to the private key. In fact, the PKCS #12 standard can also be used for protecting certificates, CRLs, or other miscellaneous information. Moreover, password-based protection is not the only method. It can use public-key encryption or even no encryption at all, so information remains unprotected.

In the password-based protection mode, the symmetric key used is derived using PBKDF2. In particular:

  [...] Specifically, PBES2 should be used as encryption scheme, with PBKDF2
  as the key derivation function.


Why do some websites and programs restrict password characteristics?

I think the reason is the same as for any other input validation; to make sure it doesn't cause any problems during processing and storage. Now, for passwords this is of course completely misguided since they should be hashed and therefore neither stored nor really processed in cleartext.

I'd take any such limitations as an indication that the developers don't know what they're doing securitywise, and are probably going to store the password in cleartext. Stay away.


Is hacking email with simjacking a concern if you don't have 2FA for the email?

If an SMS alone was sufficient for login, that would make it 1FA instead of a component of 2FA/MFA, wouldn't it? There's probably a password, too, protecting the account. In this case, an attacker must both steal the password and simjack the mobile subscription for the SMS.
However, a real problem is that some services use SMS based authentication both for 2FA and password recovery. This is what makes simjacking a powerful weapon. If both factors are controlled by the possession of a mobile number, I wouldn't count it as 2FA (two-factor authentication), but merely a two-phase authentication.
On the other hand, if you use Time-based One-time Password (TOTP), instead, and if you can't recover both your password and your TOTP using your mobile subscription, you are pretty immune to simjacking.


Should I decode a base64 password before hashing for storage?

Theoretically, decoding or not decoding does not matter, because Base64-encoding is a public permutation (every sequence of Base64 characters can be decoded, and reencoded, by everybody, and this is deterministic). If Base64-encoding strengthen or weakens your password hashing function, and your password hashing function is poor and weak and should be replaced with something stronger.

In practice, some password hashing functions have limitations; in particular, most bcrypt implementations accept passwords of size up to 51 or 55 bytes, no more. Since Base64 encoding increases the data size (every 3 bytes yield 4 characters, reencoded as 4 bytes), hashing the Base64 encoding implies a lower maximum password size. For that reason, it is advisable to decode the Base64 and process the raw password.

However there is also a good reason not to decode the Base64, depending on your support library. If your password hashing implementation uses strings as input, then that code necessarily does some character-to-bytes encoding. This can imply some very inconvenient encoding issues, especially with non-ASCII characters (a simple latin-1 character like "é" has several representations in Unicode, yielding different byte sequences). It is important that this encoding is deterministic (when the password is verified, it should use the same encoding as when it was initially chosen). When you receive Base64, then the caller already did the job and presumably agrees with himself. Therefore, it is advisable not to decode the Base64, and instead to hash it directly.

Or maybe not. An alternative view is that encoding issues call for systematic processing, and it may be a good idea to systematically decode everything you receive, to ensure reencoding with the same rules (the encoding rules on the server). This might actually help if the user employs different kinds of client software, with different encoding rules.

So, really, it is up to you. Personally, I would decode the Base64, because I trust me more than other people to process Unicode strings properly, and it avoids artificially lowering the maximum password size in case the hashing function is bcrypt (other functions like PBKDF2 do not have such limitations).


How to block spammers from using my public email api

This is commonly known as a replay attack, when the attacker repeatedly transmits a legitimate message using a script. In this case, there are minor modifications to the message since the spammers change the email parameters in each message.

What you could do to prevent that is to implement a nonce. A nonce is a random string that is unique for every single request. The nonce should be generated in the back end and stored in a database. The nonce can then be embedded in a hidden field in the form. When the form is submitted, you check the nonce against the database. If it is valid, you process the request and remove the nonce from the database. By doing so, any future request using that some nonce will be invalid and thus you would prevent spammers from repeatedly re-issuing the same request.

However, a more sophisticated bot can bypass this system by reloading the page to obtain a new nonce for every replay.

Another method which is more intrusive is to implement a captcha. It will stop most spammers, but as usual, the most determined ones will theoretically still be able to write a script to bypass that as well.


How to make QR Code uncopyable - Scanning of the QR Code at consumer level

A QR code is just text, encoded in a format that is easily readable to a computer. Can you make the preceding sentence uncopyable?

You cannot make text incopyable. Forget it. It is utterly impossible. What stops me from whipping up paint.exe, and copying the QR code pixel by pixel? Or place it on a scanner and print thousand copies?

QR codes relies on that the smart phone is able to make a copy of the content. When you scan it with your phone, the picture is a copy of the content. The picture is decoded, and a new copy of the information is made, this time as a text string.

So what you ask is not only impossible, it strikingly impossible. You must look elsewhere for how to solve your problem - for instance by invalidating the data in some online database.


How did "tech-supportcenter" phishers trick Google?

If displaying the wrong URL in the tooltip requires Javascript, how did tech-supportcenter get their Javascript onto the Google search results page?

The scammers did not manage to inject JS into the search results. That would be a cross-site scripting attack with much different security implications than misleading advertisement.

Rather, the displayed target URL of a Google ad is not reliable and may conceal the actual destination as well as a chain of cross-domain redirects. The scammers possibly compromised a third-party advertiser and hijacked their redirects to lead you to the scam site.

Masking link targets is a deliberate feature of Google AdWords. It is generally possible to specify a custom display URL for an ad link which can be different from the effective final URL. The idea is to enable redirects through trackers and proxy domains while keeping short and descriptive links. Hovering over an ad will only reveal the display URL in the status bar, not the real destination.

Here is an example:

I'm searching for "shoes".
The first ad link displays www.zappos.com/Shoes:

When I click on it, I actually get redirected multiple times:

https://www.googleadservices.com/pagead/aclk?sa=L&ai=DChXXXXXXXd-6bXXXXXXXXXXXXkZw&ohost=www.google.com&cid=CAASXXXXXp8Yf-eNaDOrQ&sig=AOD64_3yXXXXXXXXXXXXXYX_t_11UYIw&q=&ved=0aXXXXXXHd-6bUXXXXXXXXXwIJA&adurl=
-- 302 -->
http://pixel.everesttech.net/3374/c?ev_sid=3&ev_ln=shoes&ev_lx=kwd-12666661&ev_crx=79908336500&ev_mt=e&ev_n=g&ev_ltx=&ev_pl=&ev_pos=1t1&ev_dvc=c&ev_dvm=&ev_phy=1026481&ev_loc=&ev_cx=333037340&ev_ax=23140824620&url=http://www.zappos.com/shoes?utm_source=google%26utm_medium=sem_g%26utm_campaign=333037340%26utm_term=kwd-12666661%26utm_content=79908336500%26zap_placement=1t1&gclid=CI3vqXXXXXXXXXXXXXBBA
-- 302 -->
http://www.zappos.com/shoes?gclid=CI3vXXXXXXXXXXXXXMBBA&utm_source=google&utm_medium=sem_g&utm_campaign=333037340&utm_term=kwd-12666661&utm_content=79908336500&zap_placement=1t1

Obviously, Google has strict destination requirements for ad links in place and an ordinary customer won't get their ad approved if they set the link target to a completely different domain. But scammers do occasionally find ways around the vetting process.
At least, Google's policy about "destination mismatches" is pretty clear:

  The following is not allowed:

  Ads that don't accurately reflect where the user is being directed
  [...]
  Redirects from the final URL that take the user to a different domain [...]

Trusted third-party advertisers may be permitted to issue cross-domain redirects, though. Some of the exceptions are listed here, e.g.:

  An example of an allowed redirect is a company, such as an AdWords
  Authorized Reseller, using proxy pages. [...]

  For example:

  Original website: example.com
  Proxy website: example.proxydomain.com

  We allow the company to use "example.proxydomain.com" as the final
  URL, but retain "example.com" as the display URL.

One major weak spot is that Google doesn't control the third-party redirectors (in above example, that's pixel.everesttech.net). After Google has vetted and approved their ads, they could simply start redirecting to a different domain without immediately getting noticed by Google. It's possible that, in your case, attackers managed to compromise one of these third-party services and pointed their redirects to the scam site.

In recent months, there have been several press reports about an almost identical scam pattern, e.g. this report about a fraudulent Amazon ad whose display URL spells out amazon.com but redirects to a similar tech support scam.

(By now, your discovery has also been picked up by a few news sites, including BleepingComputer.)


Can they tell which individual computer was torrenting on shared internet connection?

Consult Shaw's TOS and AUP  http://www.shaw.ca/terms-of-use/

He probably got two notices, one being a DMCA copyrighted material download and the other being that excess upload traffic was being used. This is common on cable systems where the upload channel involves shared resources and abuse affects everyone on the system

As to Who, Shaw doesn't really care who's behind the NAT, the complaint is against the IP address and it's up to the internal users to hammer it out or lose the service per the Shaw TOS/AUP agreement.


You are asking a couple different questions at once: how is ML implemented by a certain vendor, and how could it be implemented to be effective. Let's focus on the later.

I have designed such algorithms for a major global financial institution, and I can give you the broad strokes.

It's not too good to be true. Any security analyst will look at the logs, get to know how people operate in the company, and "get a sense" for what "normal" looks like. It's called 'baselining'. After some time, you "just know" when something looks fishy and you need to investigate because:

The network goes quiet every Friday afternoon (for reasons that are obvious to any human in the office at the time)
Network bandwidth gets maxed when the World Cup is on (streaming, not DDoS)
That server always throws that error (a bad config no one knows how to fix)
The user can never remember their passwords and always gets locked out
We just turn a blind eye to that exec because everyone is afraid to tell them to behave more securely
etc.

Every other oddity, whether excessive errors or abnormally low errors (hey, why didn't that server throw that error?) deserves investigation. This used to be infosec bread and butter, but now goes under the fancy term of "threat hunting".

But this baselining is easy to teach a computer. And you are correct, it all depends on the ability for the computer to understand what is 'normal'.

It would be a crude approach to take the current state of the network and determine that that is 'normal'. You would train your algorithm to accept bad behaviour. You still do this as a factor, but you cannot depend on it entirely. You need another way of looking at the data. There are a couple ways to add another perspective.

There are lots of fancy terms, but when I talk to non-algorithm people, I use the terms: 'weirdness' and 'badness'. Baselining the current state helps to determine 'weirdness'. If the network is already hacked, and the hacker is freely floating around the network, then that is not 'weird' for this network. It's 'bad', but not 'weird'. If we are good at determining 'weirdness', then we can see if a new hacker comes in, or if the current hacker changes tactics.

We can augment the network baseline by determining what is 'weird' for user types by baselining subsets of the network. Devs act a certain way, execs act a certain way, cleaning staff act a certain way. If a cleaning staff account normally acts like an executive account in our current state, then we have something to investigate, even though it is 'normal' in the current state. So, this recursive baselining is one way to augment the ML perspective.

Another way to add to the perspective is to define 'badness'. Things might be normal, but we can define that activity as categorically 'bad'. It might be 'normal' for this printer to be trying to log into every server in the DC, but we know that this is categorically 'bad'. So, if we can input these parameters into the algorithm (a lookup into a signatures table), we can expose the badness in our otherwise normal network activity.

I first got into UBA after I ran a demo of a new UBA product about 3 years ago. I knew my network backwards and forwards, and instinctively knew what was normal and what wasn't. I looked into the UBA product as a backup for me and my small team to cover that skillset for when people were on holidays or if people left the team. I wasn't expecting much. But the product included this 'badness' perspective that instantly (within 2 hours) exposed badness in my network that I never knew was there even though I had baselined and was performing threat hunting daily.

ML is not too good to be true. It's not perfect, but it is better than humans at breadth, speed, and consistency.


is there any way to exit meterpreter without exit the process?

Have you tried changing the meterpreter option EXITFUNC to thread when generating the meterpreter payload?


How to prove to a 3rd party that some user logged in?

So you say the problem is, that the 3rd party does not trust you.

I don't see a simple solution. Since the 3rd party doesn't trust you, you need a signed confirmation from the user for each data package he has received from the server.

Then also the user should not trust you. The user can expect that you want to blame him in accessing some sensitive data that user actually has not requested. That's why the user (client) should sign each request and the server should include this request into its response.

So far it looks complicated, but not yet much complicated.

Now look at the implementation. For a PKI based signature browser needs access to the client public key. From the pure JavaScript you cannot do that. You would need either some browser add-on to make user key / certificate accessible from JavaScript. Or you need a non-browser client (Java, C#, Python, ...) In case of add-on user again should no trust it and needs at least the full source code of this add-on. In case of non-browser application again user needs a full source code of the client application.

Instead of PKI, you can use some other scheme for authentication, e.g. some hardware key like YubiKey or Titan. But still the solution will be not trivial.

A simpler solution could be following.

On the server side you log any sensitive operations the user has triggered, any data the user has accessed. When the 3rd party requests any information about user activities, you extract information from the log, send it to the user and ask him to confirm (to sign) this part of the log. User signs it; it doesn't need to be in browser, it can be some offline too). You send this signed log to the 3rd party. User has the right to refuse to sign such a log when you ask him. In such case you  have the right to deny user any further access to your server. This scheme would be much easier to implement.


Is Two-way SSL sufficient for Multiple web servers communicating to each other?

This sounds like a good plan. Some things to consider are:

Private keys need to be private.  That likely means a secure store with some kind of password/key to unlock the store. Frequently OS or framework support is easiest. HSMs will be a more secure alternative but I'm guessing that they would be overkill in your situation.
You need to provide authorization when one server is talking to another. Having a special user account for the remote servers frequently makes sense (and looks like what the library supports).
Adding firewall or other authentication rules to restrict IPs for cross server communication can add security.

It sounds like you're on the right track.


Why does our network firewall drop netbios-ns packets?

Generally it is a good idea to disable bot NBNS and LLMNR. This is due to the fact that both protocols perform name resolution through either broadcast (NBNS) or multicast (LLMNR) which is not safe.

For an attacker its possible to perform a MitM Attack using spoofed answers. When you have WPAD disabled there is a wider attack surface. WPAD is the Web Proxy Autodiscovery Protocol which is used by Chrome and Internet Explorer to automaticly receive a Proxy configuration. This can be used to MitM all web based traffic from Chrome and Internet Explorer users. When it comes to the Internet Explorer there is a particular critial problem. The Internet Explorer will send your credentials via NTLMv2 to the attacker if the WPAD service he is providing is aking for it. There is a well implemented tool to perform these attacks which is called Responder.

In a modern environment you can disable both without facing any problems. When you have mac clients you should also disable MDNS which is apples equivalent of LLMNR.


The GDPR isn't just about storing sensitive data, but it's more general. In fact, it's actually about processing personal data. Here are a few interesting quotes from the GDPR that you might want to consider (emphasis added):

Article 2(1) - This Regulation applies to the processing of personal data wholly or partly by automated means and to the processing other than by automated means of personal data which form part of a filing system or are intended to form part of a filing system.
Recital 15 - In order to prevent creating a serious risk of circumvention, the protection of natural persons should be technologically neutral and should not depend on the techniques used.
Article 4(6) - ‘filing system’ means any structured set of personal data which are accessible according to specific criteria, whether centralised, decentralised or dispersed on a functional or geographical basis;
Article 32(1) - Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate: [...]
Article 32(3) - Adherence to an approved code of conduct as referred to in Article 40 or an approved certification mechanism as referred to in Article 42 may be used as an element by which to demonstrate compliance with the requirements set out in paragraph 1 of this Article.
Article 40(2) - Associations and other bodies representing categories of controllers or processors may prepare codes of conduct, or amend or extend such codes, for the purpose of specifying the application of this Regulation, such as with regard to: [...] the measures to ensure security of processing referred to in Article 32;
Article 42(1) - The Member States, the supervisory authorities, the Board and the Commission shall encourage, in particular at Union level, the establishment of data protection certification mechanisms and of data protection seals and marks, for the purpose of demonstrating compliance with this Regulation of processing operations by controllers and processors. [...]

To sum up, if you process personal data in an organized way, the GDPR applies to it. An array of strings containing personal data stored in volatile RAM could be considered a "filing system", for example. The GDPR doesn't tell you any details about the security controls you should implement. However it does tell you that it all depends on the level of security appropriate to the risk, and it also tells you that you there might be certification bodies or specific codes of conduct for certain fields that will help you demonstrate compliance. In other words, if you are processing email addresses for the purpose of managing a simple student's blog, your security requirements will definitely be very simple. On the other hand, if you run a business that deals with health data, chances are you need to consult a lawyer (or more than one), and think about getting some ISO certifications for example.


Send a CA certificate via email without a digital signature?

He should still sign the e-mail. While you are correct in saying that the certificate itself cannot be forged since it already contains a digital signature from the issuing CA it is still arbitrarily copyable.

A signature on the E-Mail (or any other document) adds the proof, that subject actually does know and control the private key and is able to use it for future secured communication.


You do not want to use a fixed salt for a given user because it could lead to salt reuse, which is bad (that's the capital sin of salts, since the whole idea of salts is not to be reused; they have no other function). Salt reuse can occur, practically, for the two following reasons:

If a user changes his password, the new password will use the same salt than the old. That's bad, because old passwords are still valuable (since users reuse passwords, the old password can be the password that the user will set next month; it can also be the password for the same user on another site), and the reuse will allow the attacker to attack both the old and new password for the cost of one brute force.
If the salt is derived from the user name, then another instance of the server software, on a distinct server, may end up with the same salts, because "Administrator" tends to always be called "Administrator". Attackers could precompute a big table (e.g. rainbow table) for "Administrator", applicable to many sites (which would make table building worth the effort).

I usually sum this up by stating that salts must be unique timewise (no reuse of an old salt value) and worldwide (no reuse of salts anywhere, even on a distinct server). Such uniqueness is hard to get, but there is nonetheless a rather simple way, which is to generate big enough salts (e.g. 128-bit salts, as bcrypt uses) at random.

Summary: not generating bcrypt salts randomly would not be more secure; at best, this would be equally secure, but, more probably, less secure.


Priority of GnuPG subkey selection during encryption

GnuPG always selects the newest valid (sub)key for the respective operation (usually, the newest non-revoked key with a supported algorithm). Even if you select a specific subkey, GnuPG first resolves the associated primary key and then starts this selection process. To override this, postfix ! to a given key. This is something you might for example do in your git configuration if required.

I am not aware of any normative reference though (apart from the GnuPG code): neither RFC 4880 (OpenPGP) nor the GnuPG man page or manual seem to define the behavior. The relevant lines of code from the key comparison function:

if (old->validity == new->validity && uid_is_ok (&new->key, uid)
    && old->creation_time < new->creation_time)
  return -1;      /* Both keys are of the same validity, but the
                     NEW key is newer.  */


How do I restrict network access to websites using a monitoring system?

One possible solution to this problem is changing the /etc/hosts file (or equivalent) on the target system to point to a webserver running on the local intranet displaying your message of choice.

Example on Unix-like (Unix, Linux, BSD, Mac) systems:

# Static table lookup for hostnames.
# See hosts(5) for details

127.0.0.1       localhost
::1             localhost

your_webserver_ip blockedsite.com

A simpler approach (without the webserver) is doing this:

# Static table lookup for hostnames.
# See hosts(5) for details.

<snip>

172.0.0.1       blockedsite.com

The Windows equivalent to this file is C:\Windows\System32\drivers\etc.

Do note for all these examples you will have to have root/admin privs.


As long as the binary is linked dynamically, you should be able to LD_PRELOAD it with custom strcmp implementation which you can hack to be more "cooperative" with timing attack.

If the binary is linked statically, you'll have to use some more precise time measurement - perhaps utilise HPET somehow?


Certificate extensions - specific constraints

There are mostly two main ways, one of which using certificate extensions, and one of which being a bad idea. These two are the same...

In a certificate, you can encode "usages" as part of the Extended Key Usage extension. In your terminology, you would define some OIDs for actions A, B, C and D, and put only OIDs for A and C in the certificate.

What is bad about it is that your are conflating authentication and authorization into a certificate, and certificates are not good at authorization. To be clear:

Authentication is about making sure who is calling. That's what certificates are for: they bind an identity to a public key, and the transport protocol (e.g. SSL) makes sure that the caller controls the private key corresponding to that public key.
Authorization is about deciding what a given individual should be allowed to do. It normally takes place after authentication.

Certificates are not good at authorization tasks, for a variety of reasons, in particular because the only mechanism which can "cancel" a certificate is revocation, which is asynchronous (it can takes several hours or even days for a revocation to propagate through CRL) and all-or-nothing (you cannot revoke a certificate partially). In your situation, this would mean that if you want to lock out a specific application, the locking-out will take hours to be effective; and you cannot remove the right to do action C without removing the right to do action A. Similarly, if you want to grant a new access right to a client, you have to issue a new certificate, and send it to the client; if the client stores its certificates on a device (e.g. a smart card), this can raise usability issues (a basic PC can use smart cards out of the box, but writing into the smart card requires some specific software).

For these reasons, you really should use certificates for authentication only. In a client/server context, the certificate is used by the client to demonstrate its identity to the server, but the authorization is a decision which is purely server-side. There is no need for the authorization data to ever occur on the client side.

In a Microsoft / Active Directory world, authorization would be embodied by ACL and group memberships on the AD servers. The certificates are used to map the requester onto an account, but the rights granted to that account are maintained in the AD server, not in the certificate.


Where is the client id stored depends on the architecture of your web application. OAuth 2 defines two client types - public client (which cannot keep client credentials secret) and a confidential client (which can keep client credentials secret).

In any case, the client id is not a secret. This is what OAuth specification says about the client id:

  The client identifier is not a secret; it is exposed to the resource
  owner and MUST NOT be used alone for client authentication

When it is a confidential client, then the client secret is used to authenticate the client which must be protected. Public clients are generally not authenticated. Many other aspects are validated (one example is redirect url, check the spec for the specifics).

Can an attacker access your API if they get holder of your client id? No, unless they know your client secret. If it is a public client, even then the attacker still needs to provide valid user credentials to obtain the authorisation code, before they can use it to get the access token. Do check out the Threat Model for OAuth for a detailed overview of the threats.


How to prevent other hosts on the same LAN from seeing my IP and host name?

Actually, I disagree with tylerl's answer. It is indeed difficult to hide our IP from other hosts on a LAN, it's very possible.

Because you're mentioning netcut (a tool that works by using ARP poisoning), I think you have the following setup:

You trying to use the Internet.
Router giving you access to the Internet.
Other hosts on the same LAN.
Some malicious hosts trying to cut off your Internet connection.

The idea is quite simple: All you need is to block all inbound connections to your computer and all broadcast communications from your computer. This requires a slight knowledge of the network (at least the router's MAC and IP address) as you'll have drop all ARP requests (in and out). The only thing left to do is configure the router's IP address as your gateway and only communicate with it.

That method will indeed keep you hidden on the network as only the router will know of your existence. It will also protect you from netcut as your IP will not show on other hosts' ARP tables. However, this will not protect you from other ARP poisoning attacks that can spy on your connection and even completely cut you off.


Is there a way to split up my SSH Key using Shamir's Secret Sharing?

Shamir's Secret Sharing is a nice algorithm to split a secret value into several pieces, and allow recovery with a threshold; meaning that you split (for instance) the secret into ten shares, such that any three shares are sufficient to rebuild the secret.

This calls for two comments:

The algorithm's main advantage is its threshold mechanism; it does not make much sense if all shares are needed to rebuild the secret. In the described scenario, with SSH keys, it is unclear what this threshold mechanism would mean. There is a scenario where you want something like that (I have seen it deployed in production; see below) but it involves several key owners.
Though the shares are separated, the rebuilding process must occur, by necessity, on a single machine which obtains, at some point, the secret itself. In particular, if you do the reassembly on a machine which is evil (i.e. which is under the control of an attacker through some subreptitious malware), then the attacker learns the SSH private key, and you lose.

The scenario where the threshold mechanism with SSH makes sense is the following: there is a very sensitive server somewhere (a Certification Authority), which must never be administered by a single administrator without any witness. However, the server is remote, and some remote administration must still take place. So the idea is to have a special private key, authorized for root login (the public key is in /root/.ssh/authorized_keys). The corresponding private key should be accessible only on a machine which is assumed safe (a machine dedicated for the task and kept safe through normal mechanism -- in that case, a Linux system with sane sysadmin procedures). When remote administration must take place, a quorum of key owner collaborate, enter their "shares" on the machine, and thus unlock the private key. They keep the sysadmin under eye control for the whole duration of the administration procedure.

In that scenario, a secret sharing scheme would make sense. However, the "shares" are big numerical values, which must be stored on physical devices, not in human brains; this was inconvenient. Moreover, usual SSH client software does not allow for plugging arbitrary secret sharing systems (not easily at least). So the practical solution was the following: the private key was stored several times, each time protected by a password split into two halves; each human knew only one half. If there are n share owners, then the private key must be password-encrypted n(n-1)/2 times (so with n = 5, this means 10 copies of the private key, each encrypted with a combination of two password halves). When remote administration must take place, two key owners select the corresponding encrypted private key file; each owner types his password half, and the connection occurs.

The system works in practice. It does not scale well (with n key owners and a quorum of t, it requires O(nt) encrypted files, for all combinations), but for small values it is perfectly workable.


SQL Server of my hosting provider allows me to see all databases. How secure is my mine?

It is possible to have the rights to list the databases and not have the rights to use the database.  The only way to know for sure would be to try and access one of these databases.

That being said,  an attacker could use a privilege escalation vulnerability in MS-SQL to gain admin rights and then can access any DB.  But this is a known problem with shared hosting and this is one of the reasons why it is less secure.


How to prevent attacks against client side validations?

To do 10 checks on the server side is likely not going to put any real stress on your server. Unless you are at the point of thousands of request per second, you will be okay. At that point, you would probably implement clustering, etc. Security is always worth the extra cycles. Client side validation is never sufficient. When you think about validation, you should think about filtering RAW HTTP without regard for the fact that the "browser" may have generated the content.

Even if there is client side validation, there are still Man-in-the-middle attacks, where they can change the content of the raw HTTP request after the validation has occurred. Client side validation is really for end user convenience so they don't submit, then get an error message and have to resubmit. I would not consider client side validation in a browser based application to provide any security for processing being done on the server.

As for how an attack can modify your validation, it would depend on many things. For example, what are the dynamic values on the page - do you take parameters from the query strings (GET parameters) without filtering? This could lead to XSS or CSRF attacks because they can change those values and your application will process them. Of course you can protect against this with proper escaping and other techniques. The attack may also have loaded some type of user script or proxy which can inject code into the page.

Since you are using "reflected", you may want to read more specifically about a "reflected XSS", which is just one type of attack vector. From OWASP:

  Reflected attacks are those where the injected code is reflected off
  the web server, such as in an error message, search result, or any
  other response that includes some or all of the input sent to the
  server as part of the request. Reflected attacks are delivered to
  victims via another route, such as in an e-mail message, or on some
  other web server. When a user is tricked into clicking on a malicious
  link or submitting a specially crafted form, the injected code travels
  to the vulnerable web server, which reflects the attack back to the
  user’s browser. The browser then executes the code because it came
  from a "trusted" server.


Why would you use random algorithm for CSFLE if you can't query the inserted data?

But why would you want to store anything that you don't want to or can not query later?

It looks like you are mixing up "querying against those nested fields" with "retrieving data from the database". The first is about doing a query to find records matching specific criteria, i.e. get the user with a specific email address.  The latter is about being able to retrieve a full object back from the database.
With randomized encryption each instance of a specific email address will have a different encrypted value. It is unknown what value this will be without known the random initialization vector used in encrypting the object. Since it is impossible to know the expected encrypted value it is impossible to efficiently search for it. Instead the whole database would need to be scanned, every object decrypted and only then one could check the email address inside the object.
With deterministic encryption all instances of the same email have the same encrypted value though. That's why the encrypted value is known and it is possible to efficiently search using the encrypted value, i.e. no need to decrypt every object in the database first.


Independent C library or function (on Linux) to programmatically generate a self-signed certificate

Is there a simple C library or function to programmatically generate a self-signed Certificate in C on Ubuntu?

One that isn't OpenSSL on a base Ubuntu system? No.

I am looking for a native small stand-alone library just for this purpose with possibly added functionality but not with the full-weight of TLS implementations such as openssl, boringssl, mbedTls, etc.

It may be possible to isolate some of the code and make it into a standalone method somehow, but I'd discourage this route. It's unlikely that such a tool or library exists for this task on its own.
Use a known, maintained TLS library for this. Even if it will ever only be generating self-signed certs.


Store cookies for multiple sites on remote server and connect from multiple clients

No, it won't be any practical nor solve anything.
First, there are cookies set or read from Javascript. Those cookies won't be stored on the server and will be different on each device. Every site using them will fail somehow. Sites that store the browser on a session variable will detect that your cookie was used with Firefox mobile and desktop, and may lock your session or password for suspected session hijack.
Second, it increases the complexity considerably, without any benefit. Having a custom VPN on each device is costly, both on speed and on battery consumption. Using a proxy on the server would be simpler, but will reduce speed as well.
Third, you will have to install a custom CA on each device, intercept the SSL connection server-side, create a certificate on-fly and encrypt the connection with the generated certificate before sending to the client. This is a huge issue if someone hacks into the server (more on this later).
Lastly, you will have to maintain a backend infrastructure to store and manage every cookie, and write a custom process to check every HTTP header, strip all cookies, store them securely, and send to the client. On the other side, you will have to intercept every connection from every client, search for cookies, alter the request, and add the cookies.

I could keep diverse and very strong passwords for every website

You would better use a password manager for that.

logging in to all the sites I use on a new device only requires one sign in

With a password manager, one keystroke will login you back.

If the authentication to my custom VPN is cracked, then every website I've logged into would be accessible

Only cookies would be stored digitally, so if anything went wrong server-side, my passwords would be safe

Not even close. The cookies are the least of your problems. If something goes wrong server-side (like an attacker compromising it), the attacker will be in position to MitM every single HTTP/HTTPS connection you have. They have the private key of your custom, trusted CA, and can create valid certificates for everything. A custom CA enables you (and the attacker also) to bypass HSTS validation, so even websites protected by HSTS will be able to be attacked.
Imagine downloading a driver for any device you have, and the attacker changing the download on-fly to embed a root-level backdoor and keep the device signed. Or going to your bank to transfer money to someone, and the attacker changing server-side all transfer details but keeping the client-side unchanged, so you put the destination account on the form, read the confirmation page with the correct destination, press "Confirm" to send the money, read the confirmation page with the correct details, but server-side the attacker wired the money somewhere else. And that is possible because of the custom CA and the interception proxy.
They will have access to every single website you already accessed, and have access to every single website you access from that point on, being able to read and change anything at will. And be able to even change sites that you never accessed before, even when you don't use your custom proxy.
How? HTTP Caching. He can backdoor, for example, https://cdnjs.cloudflare.com/ajax/libs/jquery/3.5.1/jquery.js or https://code.jquery.com/jquery-3.5.1.js and put a very long expiration date. As soon as your browser cache this backdoored version, it does not matter if you are using the proxy or not, every site that uses this CDN version of JQuery can be compromised.

It's not as cool?

For me, looks like a disaster waiting to happen...


Why should you generate SSH keys on client devices?

Because most guides are written for people who are not experienced and it is assumed to be safer (by reducing possibilities for mistake) to prevent the private keys from being transmitted/stored outside of the client on which they were generated. ssh-keygen command also automatically sets the limited permissions to the generated private key reducing the number of steps required.

Where you generate the keys and how you distribute them depends solely on the process (in the "management process"-sense). As long as you do not the compromise security by using an insecure generator or an insecure channel, the exact place where you generate the key pair does not matter. It might as well be a third machine.


my email just hacked, no 2 factor auth. request or new sign in? Am I infected?

It's a simple spoofing attack. Gmail is showing sent items not based on what was truly sent but on "from" address that matches your e-mail address. So you received an e-mail that has your e-mail address as to/cc/bcc and from at the same time, you will see in there but the e-mail wasn't sent from your account.

to check that, grab headers from original of one of the spam emails and drop it in this tool, and you will see under section "from" who originated it.


Can a BIOS or UEFI infection transfer to other storage drives without the OS presence?

There is always an operating system, albeit not necessarily a complex one. The BIOS is an OS in the strict sense of the term: it provides access to hardware through an hardware-independent API. The boot code for an OS (or some malware that pretends to be that boot code) uses the BIOS-provided API to read (and possibly write) bytes from the hard disk.

Theoretically, nothing would prevent a piece of malware, installed as "boot code", to use the BIOS to observe the hard disks, locate "infectable" files, and infect them. This would imply making sense of the filesystem structure, which is normally a job performed by the "big" OS (the Windows or Linux or OS X or whatever). If the malware wants to do this by itself, then it must include the code to do so, which can be bulky, or take some non-negligible development effort. Thus, while it is possible, it can be expected that most malware authors, being no less lazy than any other developer, will prefer to avoid it. Booting a "normal" OS and then using its facilities to access files is easier.

The GNU GRUB bootloader is not at all malware; it is a piece of software whose job is to leverage the low-level disk accesses of the BIOS to locate and load in RAM the core elements of an operating system to boot (e.g. the kernel in the case of Linux). As part of its functioning, it includes support for many filesystems. A malware author who wants to locate and infect files in filesystem from a "bootloader" environment would probably reuse parts of GRUB. In any case, GRUB demonstrates that filesystem support code can be compact enough to fit in the constraints of the bootloading environment.


Could Diffie-Hellman be used to stop people who knows the PSK from snooping on your WiFi?

In creating WPA2-AES, priority was given to 1) using the passphrase to ensure that the client was authorized to use the system, and 2) ensuring that there was no way for the client to inadvertently expose the passphrase to someone posing as the host. It succeeds at these two things. It was not created with the intention of providing full secrecy between clients, since they are often sharing the same layer two network anyway.

As your summary states, DH is designed for establishing an encrypted tunnel between any two hosts via a handshake that is (at this point) invulnerable to third party snooping. It does not provide authentication however. In order for WPA2 to take advantage of this it would need to execute the entire DH exchange, and then perform the WPA2 4-way handshake so that it can authenticate the client while still making it impossible for a malicious host to pick up the passphrase from an unsuspecting client trying to connect.  However, in executing the DH exchange the client still hasn't validated the host.  It would still be possible for a man in the middle to pose as the host, perform the DH exchange, and then pass the encrypted traffic on to the actual WPA2 host to perform the 4 way handshake, rendering the additional DH step useless.

WPA2-enterprise (using 802.1x and radius) allows for each client to create a passphrase and ultimately a key that is unique to their connection, providing inter-client secrecy.


Difference between Code Injection, Command Injection and Remote Code Execution

Hmm let me try:

Code injection consists of modifying an executable / compilation unit / script so that it contains malicious code on top of it´s intended functions. Code can be injected locally into it and then it could be uploaded into the internet, forums, news servers etc. It is a rather easy form of exploit and similar to a trojan horse. Early viruses were made like this, and spread via users sharing executables. You probably find this still today in "key generators" and other illegal software, as well as in data files like the notorious windows sreensavers ".scr" and other formats that aren´t executables per se but can be loaded with code that gets executed.
Command injection is IMHO using the weakness of an unprotected system to allow execution of arbitrary commands to modify or damage the target system. This could be for example to inject instructions via web URLs and make the remote server execute them. Unguarded SQL strings became famous for this. Either they can corrupt the database or even execute code on the underlying OS.
Remote code execution is to actually again craft malicious code but this time it is not attached to the binary unit, but send via the network. The difference to command injection could be seen in that additionally to the malicious code / script it also needs a weakness or fault of the receiving process, like you would send over a wrong instruction, make the process crash, and then make use of the crash handler to execute code that has been delivered together with your "crash packet". Most modern "zero day" exploits work like this.

I think the terminology is used in a fuzzy way though, so other people might see this different.


Why WPA2 Client Devices Respond to Any Deauths

Why do clients respond to any deauth request they hear instead of verifying the origin?

They don't respond to any deauth/disassoc frame they hear, they only respond to such frames that are addressed to them and sourced from their AP MAC address. And yes, this by the nature of 802.11 wireless would include frames with spoofed source addresses.

  Also, will this be addressed in the upcoming WPA3 standard?

No. First, WPA3 is not a standard, it is a specification for getting a particular certification(s) from the Wi-Fi Alliance for a device. The IEEE defines the 802.11 wireless standards and there are no working groups working on any amendments that change the essentials of 802.11i (which the WFA's WPA2 certification is based on). Please see my answer here for more on what WPA3 is if you like.

Second, there is no need to do so. This was addressed in an amendment by the IEEE that was ratified in 2009, namely 802.11w. The issue is that implementation of support for this amendment has been slow by certain vendors outside the enterprise environment. Check out my answer here for more.

  It seems to me this would be a basic thing that should have been implemented as part of WPA2 to prevent easily giving away of the handshake and to prevent someone from doxing the connection.

PSK as defined by 802.11i (WPA2) was meant for basic, personal use. It was intended for simplicity and ease of use. If an entity wanted better security, 802.11i defined the use of 802.1X and RADIUS to provide such.


Auto log-out sequence based on inactivity on desktop devices

If an attacker can write to specific memory locations to prevent logout, you're already severely compromised.  Any attacker that can change arbitrary memory can write arbitrary code to it.

If an attacker can read specific memory locations, you're also very likely severely compromised if you store anything in memory you wouldn't want world+dog to know.


Secure symmetric encryption of passwords to allow admins to log in as users

Generally, it's good practice to allow some other method of impersonation. By allowing administration staff access to passwords, you lose the ability to verify that a given user has performed a given action - it might be the original user, it might be your admin staff. It also compromises any users who happen to re-use passwords on your site and elsewhere - it would only take one admin user writing down the username and password, and finding the same details in use on another site.

If you must allow logging in as another user, the admin staff should reset the password to one they know, make whatever changes they need to do, then enforce a password reset when the user next logs in.

In short, don't do this - either implement another method of impersonation, which logs the admin user who accessed the account, the time, and what they did, or make use of your existing password reset processes, and ensure that the password known to the admin staff is changed the next time the user logs in.


AES Key Management / How To Swap Encryption Key

Encryption keys can have a cryptoperiod after which those keys shouldn't continue to be used for encryption. This may be due to security policies, due to an individual who knows a key component leaving the business, due to suspicion of an encryption key compromise etc.

Often, a business will use an encryption key (let's call this keyA) for encryption for X period of time. Following that period of time a new encryption key (let's call this keyB) will be generated and used for encryption.  The encrypted data will be stored with a reference to the key it was encrypted with so the application knows what key to use for decryption. Using our naming above, keyA could be considered invalid for the encryption of new data but could be used for the decryption of data encrypted using that key. KeyB may currently be valid for both encrypting and decrypting data.

As your data is probably stored according to defined data retention periods, once legacy data is purged, older keys may also be removed as they are no longer required for the decryption of data.

Per your post, decrypting and re-encrypting large volumes of data can be time consuming and process expensive.


You just need a way of reliably starting the process after the machine has booted.

This can range from -

asking Windows or another process to start it on boot (service, startup application etc)
Replacing or patching an executable or library known to be called at or soon after boot. This can include drivers.
Hijacking a common user action - for example modifying Google Chrome shortcuts to launch your own process (which in turn starts the original application to stop the user realizing).
Replace / patch bios / firmware running on a hardware device.
Use a bootkit / hypervisor to start your code before the operating system.
Physical hardware based attack - something like a malicious RAM module that injects code.

You can also do things like modify the firewall and service settings to allow reinfection remotely.


Is microcode physically able to mitigate Meltdown?

I've seen a satisfactory answer on an LWN thread. Taken from a comment made by jcm:

  I doubt it’s possible in microcode. Let’s look at it:

  Speculative loads. Only thing you could do in microcode is turn off all speculation, or maybe cause every load to be serializing (similar).
  Branch prediction. You could turn off the indirect predictors (but that’s what IBRS does).*
  Permission checking during speculation. You can either turn off speculation or the cache, or kill the TLBs or you’re pretty much out of options.

  You can’t just replace random instructions in microcode, or add complex behavior, for several reasons:

  Not every instruction is microcoded. Fast path instructions don’t even touch the microcode sequencer.
  The patch RAM for the microcode is tiny and can’t carry anything like that kind of patch.
  Complex TLB and branch predictor logic isn’t under direct algorithmic control via microcode, only certain aspects of it are. You can alter behavior, tweak chicken bits, play with control signals...but you can’t add what isn’t already in the design.

  Microcode isn’t magic. It’s there to fix mostly run of the mill complex instructions that don’t behave correctly, or to whack chicken bits, and so on.

* This statement regarding IBRS behavior was disputed in another comment on LWN.


How do I allow websites to call my desktop app over HTTPS?

Security implications aside for a minute, it seems like this is either a bad idea or just plain won't work in many situations.

My solution, which sucks but isn't the end of the world, is to build browser extensions to communicate between the app and the browser. This way the extension can gather information about the current page, whether http or https, and send it via plaintext http to the desktop app via ajax.


Is 'account-security-noreply@accountprotection.microsoft.com' a legitimate sender of security alerts?

You can not trust that a sender address is correct. They are trivially easy to fake.

The SMTP (email) protocol allows the creator of an email to state any sender address they want. There is no validation that the sender actually controls that address. And even if the receiving mailserver does some form of sender validation, like checking if the IP address of the sender matches the domain they claim to be from, there are also some quirks in the UI of many email readers which can be exploited to display a (fake) email address as the name of the sender.

When you receive some email which claims that you need to do something on some account on some website, and this appears to be plausible (you actually have an account on that site), then take a good look at the URL the link leads to. The domain name says who controls that link. The domain name is the thing which comes before the first slash.

These URLs all lead to Microsoft:

https://microsoft.com/account
https://account.microsoft.com/account
https://account.microsoft.com/account?someTrackingId=689392356034706528902345

The following URLs are examples which do not lead to Microsoft. They all lead to a domains which might be controlled by someone else:

https://microsoft.com.example.com/account
https://example.com/microsoft.com/account
https://example.com/?https://account.microsoft.com/account
https://example.com/#https://account.microsoft.com/account
https://totallylegitaccountportaljusttrustme-microsoft.com/account
https://microsoft.com:microsoft.com@example.com

The last one is an example of a rarely used URL format which includes an username and a password (which are in this case both microsoft.com). The actual URL being requested is after the @ symbol.

If you decided that the link is probably fine, you click on it and get lead to a login form which looks trustworthy at first glance and did apparently not yet install any malware using drive-by download, then you should also check if the site is loaded over HTTPS (any reputable site will use https-only on their login form) and check if the certificate is actually signed for the company the site claims to be.

Some guides for detecting phishing attempts say that you should look for signs like broken images or non-functional links. I consider this bad advise, because it is based on the prejudice that all phishers are shoddy webmasters. The scene got a lot more professional in the past years. You should focus your attention on those things they can not fake with sufficient effort.


Does any tablet support remote attestation?

When a TPM provides a remote attestation, several components are involved:

the TPM as a tamper-resistant device containing a root of trust;
the TPM as a device to measure the software running on the main processor and produce an attestation;
software to connect to the TPM and retrieve the attestation and transmit it (this software is merely relaying a signed attestation provided by the TPM, so it need not be trusted).

The third point is “easy” insofar as such software already exists, and could be ported to tablets if there was a use for it.
The first point is a blocker in the mobile device ecosystem, because phones and tablets tend towards having very few chips; an extra TPM chip is seen a as significant cost increase. While TCG has defined specifications for a MTM (a lightweight TPM for mobile devices), I don't think an MTM found in any smartphone for the general public. Microsoft is pushing for TPM in tablets, so MTM or TPM in mobile devices may become more widespread (e.g. the new Windows Phone 8 has a TPM).
Point 2 does not actually require a TPM as a physical device, but a system component providing a TPM-like interface and running outside the reach of the normal operating system. For example, the OS (e.g. Windows RT or Android) could run in a virtual machine, with the hypervisor providing a (virtual) TPM. There are two immediate hurdles with this approach:

The Cortex-A15 is the first ARM core providing virtualization extensions. Devices with A-15-based processors are barely coming out now.
While the hypervisor can store the root of trust outside the reach of the main operating system at runtime, it needs a place to store this root of trust — that can't be the main flash memory where the OS could overwrite it.

The first hurdle can be solved with TrustZone, which provides a kind of specialized hypervisor with just two OS partitions and is present on all ARM-based processors used in smartphones and tablets (and it's difficult as a user to know what if anything it's used for). The second hurdle requires more support in the processor, but there are processors deployed in existing devices (e.g. the Motorola Droid) that provide at least a small amount of non-volatile memory in the form of fuses (physical write-once) that are only readable by the “trusted world” side of TrustZone and not by the main operating system. A TPM interface can be built on top of that, and TCG is working on it. This may well be the “firmware-based TPM” in the ARM-based Surface (which does not have a discrete TPM chip).
So, to summarize: there are pretty much no tablets with actual TPMs. But there are tablets with something that can implement the same security requirements (with a slightly lower level of confidence). You can't yet buy any tablet and expect to have remote attestation working on it, nor can you implement it yourself because you won't get access to the root of trust, but with the current hype around BYOD, more and more products should be coming out.


Providing password review results to auditors

The auditor requested the results of the password review process.

This seems a perfectly reasonable request. The result of the password review process is not a list of all passwords, but rather the information that you have gathered from the process. It could look something like this:

During the password review process, 1292 passwords were audited. 1171 of those passwords were personal passwords, and 121 passwords were for service accounts.
Out of 1171 personal passwords

58 passwords were found on publicly available leaks
25 passwords could be cracked within 24 hours
additional 7 passwords could be cracked within a week

The remaining 1081 passwords (~92.31%) could not be cracked within one week using a cloud computing platform.
[... more stuff goes here ...]
In order to improve the situation, measures will be taken to compare user passwords to known leaked passwords and reject the password in this situation.

This way, the auditor can be reasonably certain that you actually conducted a password review process. For a more in-depth audit, the auditor may want to see more documents regarding the process, such as your requirements for a secure password, how the cracking was conducted, etc.
However, no serious auditor would ever require to see plaintext passwords.


Which questions should be asked when evaluating the risk of a policy exception?

It depends on what the exception request form is for; if the policy exception relates to a service, then you'll want to ask questions about the nature of the service, e.g.:

Does the exception cover any systems which store Confidential or higher data assets?
Does the service being excepted integrate with any other services?
Is this exception covering a service which has already had a prior risk assessment? If yes, what was the risk classification given in that assessment?
Does your department interact with Confidential or Restricted assets?

Generally speaking, you're going to need more than Yes/No in most cases, imo. Just like any initial scoping questionnaire, this would probably only let you pick out very obviously-risky requests for triage.

A requestor's assessment can only elevate risk, not lower it. :P


Does two-factor authentication reduce the need for a long password?

Mostly, two-factor authentication reduces the need for strong passwords in the same way as safety belts in cars reduce the need for efficient brakes. When you drive your car, your probability to be killed during a given journey is the probability of your having an accident, multiplied by the probability of your being killed when an accident occurs. Good brakes reduce the first probability, while the safety belt reduces the second probability. For a given target probability of dying, if you enhance the safety belt (e.g. by fastening it, compared to not fastening it), then you can tolerate less effective braking.

The relationship between the authentication factors is somewhat similar. You use 2FA so that the failure of one factor does not grant access to attackers. So if a password is one factor, then the second factor can save your skin if the password turned out to be weak.

An extreme example is a smart card: most banking cards use a 4-digit PIN code, which, for a password, is pathetically weak. However, the card will lock itself after 3 bad PIN codes, making such poor passwords tolerable. The "second factor" here is physical ownership of the card: attackers cannot try PIN codes without having the card in hand and talking to the card, under the scope of the 3-bad-codes rule.

Ultimately, the choice is up to you, based on a risk analysis. Personally, I fasten my seatbelt and I keep my brakes in good conditions; meaning that when I use 2FA, this is not to allow the use of poor passwords at an unchanged risk level, but to complement good passwords for a much lowered risk level.


Can I get malicious malware in my computer or any kinds of virus by registering through Google/Facebook to a specifc site?

The potential for getting malware has nothing to do with how you register. Installing their application is a much bigger factor in getting malware.


Are there any potential security risks in connecting to a Murmur (Mumble) server?

Any time you exchange data with software you incur a security risk.  For example a client could potentially connect o a malicious server that exploits a buffer overflow in the protocol to obtain arbitrary remote code execution on the client.  If this is a concerns you find  murmur client that wasn't written in C/C++.  Managed languages,  like python, and java,  still suffer from very serious security defects but less than that of C/C++.


Storing database credentials for multi server, multi db environment

Not really a best practice answer, but your use case sounds a lot like the common problem adressed in configuration management. Configuration management applications like Chef or Puppet provide you with the means to efficiently set up and configure software on clustered systems.

Usually you set up a master system that installs and configures all your other systems like application servers and database instances. The master updates configurations every n minutes based on rules like:

When the number of application servers increased, deploy a configuration file containing all the databases credentials and start it up.
When the number of database instances decreases, update all application servers configuration files and restart them one by one.
When the number of database instances increases, get credentials for the new instances from the cloud service, update all application servers configuration files and restart them one by one.

You might also consider having the configuration management application provision your databases. In this case you could go as far as having random passwords generated whenever a new database is required, database users generated automatically and credentials published to all application servers. Strictly speaking, no human would have to get in touch with these database passwords anymore!

Finally let's state some security considerations:

Obviously the master system is a valuable target, and should be secured reasonably. E.g. it should be placed in a MZ (militarized zone) with strongly regulated network access.
The traffic between master and the other systems is usually encrypted to prevent leakage of credentials and other sensitive information.


What is the difference of TrustManager PKIX and SunX509?

From a basic usage point of view, difference is how resulting TrustManagers are initialised, as per Java Cryptography Architecture Oracle Providers Documentation for JDK 8

SunX509: A factory for X509ExtendedTrustManager instances that validate certificate chains according to the rules defined by the IETF PKIX working group in RFC 3280 or its successor. This TrustManagerFactory supports initialization using a Keystore object, but does not currently support initialization using the class javax.net.ssl.ManagerFactoryParameters.
PKIX: A factory for X509ExtendedTrustManager instances that validate certificate chains according to the rules defined by the IETF PKIX working group in RFC 3280 or its successor. This TrustManagerFactory currently supports initialization using a KeyStore object or javax.net.ssl.CertPathTrustManagerParameters.

One thing to note is, Java Cryptography Architecture Standard Algorithm Name Documentation for JDK 8, only lists PKIX as a TrustManagerFactory algorithm. SunX509 is left to provider's documentation because it is a vendor provided implementation, whereas PKIX is provided by all vendors. For example if you're running on IBM JRE, there is no SunX509, but IbmX509. Consecutively, if we hardcode "SunX509" in our application, we will receive a NoSuchAlgorithmException. Hence, for portability, it is best to use platform default algorithm as below, as both will work for keystone files (currently both Sun and IBM JREs default to PKIX).
TrustManagerFactory trustManagerFactory=
    TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());

While both factories can be initialised with a KeyStore parameter, using PKIX allows for alternatives, which can be configured using initialisation parameters. An interesting example is using LDAPCertStoreParameters for using an LDAP certificate store instead of a keystore file (an example here).


The best way to answer your question is probably going to be to hire a security consultant to perform a security assessment of your approach.  It sounds like you don't have a lot of security knowledge yourself, so you're probably not going to be in an ideal position to answer the question on your own.
You probably haven't provided us enough information for us to perform a thorough security assessment for you.  The security risks of your approach are going to depend heavily on all the details of how your system works and how it is configured and deployed.  There are a lot of details you don't mention, but which are relevant to security.
Here are some examples of security risks that might be relevant to you, depending upon your specific situation:

Social engineering. Asking users to download and run an executable program is a dubious idea, from a security perspective.  It trains users to run executables from untrusted web sites, i.e., it trains them to behave in an insecure way.  You may not intend to ever serve them a malicious program from your site, but what if the users go to some other site and download and run a program?  If you are asking users to routinely do this every time they want to use your application, you are teaching them that this practice is OK.

Man-in-the-middle attacks. You don't say whether your site uses HTTP or HTTPS (i.e., whether it uses SSL/TLS encryption).  If it is accessed over HTTP, then it is vulnerable to man-in-the-middle attacks, such as those that are possible over open Wifi.
The best defense is to ensure that your site uses SSL sitewide (it should be accessible only via HTTPS; any attempt to visit via HTTP should immediately redirect to the HTTPS site, or else your server should never respond via HTTP).  You should also enable HTTP Strict Transport Security on your server, so clients know they should only connect via HTTPS.

Access control.  You haven't told us how you limit who is able to upload new versions of the application to your site.  Obviously, the security of the site is only as good as the protection for that functionality.

Server security. If someone can hack into your server, they can breach the security of your site and your clients.  Therefore, you should lock down the server, so it is not running any other services beyond what is needed for this one application.  You should enable a firewall to ensure that no one from the public Internet can reach any service other than the web service, and possibly a well-secured SSH server for administrative access.  (For SSH, I recommend allowing public-key access only, and disabling authentication via password.)

Software security. You will need to ensure that there are no vulnerabilities in your custom software.  This means that it is important that the developers be trained in secure software development.  They might also want to use static analysis tools or other support to help catch any remaining security bugs that might slip through.

Updates. You should make sure to keep your software updated with all the latest security updates and patches.  One way to do this is to configure Ubuntu to auto-update its software, e.g., checking for and automatically installing updates once a day or once a week.

Generally speaking, it is not likely that you are going to get a definitive answer that "you are secure", just as there is no guarantee the next time you cross the street that you won't get hit by a car.  Instead, security professionals identify possible risks/threats, assess the mitigations/defenses you have put in place, evaluate whether your system reduces the risk to an acceptable level, and identify for you some possible steps you could take to reduce the risk if you so choose.


Error message in Apache logs shows /bin/bash and wget

So it looks like someone is trying to use the shellshock vulnerability which was recently discovered in the bash shell. The key give-away is the part of the log which reads:

referer: () { :;}; /bin/bash

What the attacker (or unknowing participant) has done is to set their web browser's http referer header to everything you see after the word "referer" in your log. If your server is vulnerable then the () { :;}; will cause everything following it to be executed. This could occur if a CGI script is run on a machine with an unpatched version of bash, and where that script uses the referer variable.


How to implement machine tagging when allowing a user to "remember me" on web application?

The problem with asking a machine to identify itself is that it can lie. If an attacker can steal a cookie, there is a good chance that they can also discover any information needed to impersonate that machine.

The only (partial) exception to this is IP addresses, but when you tie a cookie to an IP address you risk annoying users when their IP address changes. Unfortunately, changing IP addresses is quite common for smartphones or laptops, and may even happen regularly for a desktop depending on the ISP. IP addresses can also be shared by multiple users, so this solution isn't 100% effective. This is a trade-off between usability and security, so the decision will depend on the application.

In most cases a cookie with the Secure and HttpOnly flags is sufficient.


Why are top-level wildcard bindings unsafe?

It's unsafe because of DNS rebinding attacks, a technique which allows an attacker to bypass the Same-origin policy:

The attacker registers a domain (such as attacker.com) and delegates it to a DNS server that is under the attacker's control. The server is configured to respond with a very short time to live (TTL) record, preventing the DNS response from being cached. When the victim browses to the malicious domain, the attacker's DNS server first responds with the IP address of a server hosting the malicious client-side code. For instance, they could point the victim's browser to a website that contains malicious JavaScript or Flash scripts that are intended to execute on the victim's computer.
The malicious client-side code makes additional accesses to the original domain name (such as attacker.com). These are permitted by the same-origin policy. However, when the victim's browser runs the script it makes a new DNS request for the domain, and the attacker replies with a new IP address. For instance, they could reply with an internal IP address or the IP address of a target somewhere else on the Internet.

While the browser won't send any cookie to your webserver (unless the victim logs in), it will still execute any JavaScript code controlled by the attacker, and will be able to load pages / submit forms, like any XSS / CSRF vulnerability.
Your webserver should only reply to requests intended for domains you control.


How can I create a research botnet within VMware?

Botnets are a large and varied class of software, which do a variety of tasks, so it's not necessarily easy to provide exact examples.

With that said, if you take a typical task of creating Denial of Service conditions in the target system, then it's relatively easy to replicate the actions of a botnet with standard software.

For example say you want to DoS a web server, a standard way to achieve that is to send large quantities of traffic to the target web server port.

So to do that you can use load testing tool such as ab which generate load to a site.  Just write a script to start up 3-4 instances and see how your target fairs.

Another example of the concept would be the excellently named Bees with Machine Guns which uses Amazon EC2 instances to provide the systems to carry out the load testing.


Advantage Mutual authentication over PSK

"Pre-shared key" is indeed a valid model, and simple, if you can pull it off. Asymmetric cryptography, with public and private keys, and certificates, was invented to solve the secret key distribution problem: in general, it is hard to ensure that all pairs of systems/people who must securely talk to each other actually share a secret value. In a client-server setup, where client and server are distinct machines, then a shared secret must necessarily have travelled from one machine to the other. Travelling secrets are "less secret". With asymmetric cryptography, only public values actually go over the wires; private keys can remain local through their complete life cycle, and that's usually a good idea.

Similarly, if client and server share the same secret value, then an attacker hijacking either machine learns the secret and can impersonate both. With asymmetric cryptography, an attacker who plunders the RAM or disk of the client can later on connect to the server and authenticate as a client, but cannot run a fake server which would fool the client.

These are reasons why a pre-shared key mechanism, though tempting (it is lighter on CPU, and involves none of the dreaded X.509/CA business), make in practice imply some weaknesses, depending on how the system is installed and maintained.

(Of course, in all of the above I suppose that you do not do anything stupid, such as having a shared "secret" between the server and 10000 clients; if 10000 clients know a "secret" then it no longer is a secret. Appropriate pre-shared key systems use a different key for each client-server pair. When the pre-shared key is a human-remembered secret, i.e. a password, then extra care must be employed, because passwords are weak; this can be managed with SRP.)


Passwordless login over email - security considerations

You are correct that the security of your system is similar to that of most password reset systems. It is as secure as the email addresss - no more and no less. Be aware that some password reset processes ask additional questions (e.g. what's the name of your first pet?) which do provide some additional security.

You will have a hard time persuading a non-tech of the security of this. One approach would be to do a Threat Model of your system and show this to them. I doubt they would read it though. The thing is, computer security is far from perfect, so you really have to think about what happens if it goes wrong. If you have a breach, it may seem much harder to justify your non-standard system. There's a lot of be said for doing the same as others.

I have seen live systems that take your approach, including Doodle and RT. Some surveys also do it.

I'm curious why you reset the token after it's been used. What was your thinking?

One threat to be aware of is browser search bars. If a user has these installed, all the websites they visit may get sent to the search engine. This could end up with http://yoursite/token/ being added to Google's index, which is clearly not desirable. Your approach of one-use tokens actually prevents this. Another approach is to always use "no index" meta tags or robots.txt.

What you have created here is what I'd call "poor man's single sign-on". You may be aware that there are some standards for web single sign-on, including OpenID, OAuth, Mozilla Persona, and more. However, none of these has gained a critical mass.


Seeking advice on how to build a box to brute force hashes?

I am assuming you are already familiar with hashcat for the software aspect:

http://hashcat.net/oclhashcat-plus/

On the main page they have some system information, check the forums and wiki too. You might want to look into professional graphics cards and figure out what configuration works best. You might want to get some cheaper cpus across multiple boxes and distribute the workload.

http://golubev.com/gpuest.htm
[Placeholder for a link to a site I have to find again, but that had a good build guide]


Are there any transaction time constraints in EMV contact and contactless cards?

Contactless card uses the same chip and PIN module as in contact card. The difference between them is in the medium of communication with the terminal and in application selection. Contactless cards store additional cryptographic keys to authorise contactless transaction. As their keys are separate, the issuer can disable contactless payment by always rejecting contactless transaction authorisation request but still allowing contact payments. Some banks offer this opt-in feature to prevent unauthorised use of stolen contactless cards.
In contact payment, there are no time constraints. Contact card can even tell terminal to wait and call it again after some seconds and then it can do this indefinitely (21:01). Some terminals can also tolerate few seconds round trip delay (23:18) because contact cards are slow (600 bits per second (23:56) and transaction can be few bytes long).
The recommended transaction time for contactless payment is 500ms but it is not globally enforced by the issuers as terminals can itself add latency in processing. Most of the contactless payments take 330ms - 637ms and some terminals can allow max transaction time upto 52 seconds (16:30). This out of specs implementation is to maintain compatibility across card issuers and PoS manufacturers (In UK alone, there are almost 300 approved chip and PIN terminals). This is why relay attacks are successful.
However, there is a max allowed time length in Distance Bounding Protocol which combats relay attacks. Distance bounding is in the EMV contactless specification and Mastercard has taken up this defence, meaning its cards (at least) are protected.

ICC does not have an internal clock. For signal processing and I/O modes, ICC relies on clock signal provided by the terminal.

I/O line can be switched to (reception mode) receive data from the terminal or to (transmission mode) transmit data to the terminal.

EMV Book 1, 7 - Physical Transportation of Characters

During the transaction process, data is passed bi-directionally between the terminal and the ICC over the I/O line in an asynchronous half duplex manner. A clock signal is provided to the ICC by the terminal, and this shall be used to control the timing of this exchange.

ICC cannot measure the time between two command.


xmlhttprequest with https - can I test the fingerprint before sending any data

I found this page, but here the the fingerprint is only retrieved after a request has already been made.

You need to do some kind of request to get information about the peer, because somehow it needs to collect these information. But of course you can do a dummy request (pre-flight) not containing any sensitive data.

But note that a normal application has no access to the fingerprint or certificate. The example you refer to can only be used inside a Firefox extension or from an XULRunner application which is clearly stated:

  ...This code requires elevated privileges to run; you can only call it from a browser extension or from a XULRunner application.

Outside of these elevated privileges, that is inside a normal web application, you can only trust that the browser does the right thing but you can use HPKP to make sure that the correct fingerprint of the certificate will be used, at least with browsers supporting HPKP.


enforce some peers to use IPsec and allow others to bypass it when reaching the same server

... letting attacker to bypass IPsec authentication and Application Layer would have to make decision whether traffic was spoofed or not.

UDP is a transport layer protocol, while IPSec is a network layer protocol. Contrary to higher layer security protocols like TLS the server application will not be able to tell if the data were sent through IPSec or plain, it only sees the application data. In order to distinguish this you need to have different endpoints (IP address and/or port) for IPSec and plain traffic.

  ...for some clients, this server would expect to receive this UDP traffic encapsulated over IPsec. While for some others... without using any IPsec.

With a normal network setup there should only be a single route to the server host, which is either through the VPN (IPSec) or not. Thus a client would need to be taken outside of the VPN to connect in plain to the server or the server need to have a second address which is not in the route of the VPN.

This means the default does probably what it should do. But one has to question the decision to let all client connect by default without encryption. Instead I would recommend to maybe allow local clients (same network) without encryption, to allow for some other clients connection through VPN and to forbid all other clients to connect at all.

But I think your question lacks enough detail to decide if the setup is safe or not. I think you can build both a safe setup and an insecure setup which both match your current description of the setup.


How to tell if you're being ARP poisoned?

FF:FF:FF:FF:FF:FF is the broadcast MAC address and is associated with the broadcast IP address in the ARP table (arp -a command). Somebody could be poisoning you but you might have mistaken the broadcast IP address for the Gateway IP address.

Here are tools that provide ARP security by alerting or stopping attacks:

XArp: Advanced ARP spoofing detection, active probing and passive checks. Two user interfaces: normal view with predefined security levels, pro view with per-interface configuration of detection modules and active validation. Windows and Linux, GUI-based.
Snort: Snort preprocessor Arpspoof, detects arp spoofing.
Arpwatch: the ethernet monitor program; for keeping track of ethernet/ip address pairings,
ArpON: Portable handler daemon for securing ARP against spoofing, cache poisoning or poison - routing attacks in static, dynamic and hybrid networks.
Antidote: Linux daemon, monitors mappings, unusually large number of ARP packets.
Arp_Antidote: Linux Kernel Patch for 2.4.18 - 2.4.20, watches mappings, can define action to take when.
ArpAlert: It listens on a network interface (without using 'promiscuous' mode) and catches all conversations of MAC address to IP request. It then compares the mac addresses it detected with a pre-configured list of authorized MAC addresses. If the MAC is not in list, arpalert launches a pre-defined user script with the MAC address and IP address as parameters. This software can run in deamon mode; it's very fast (low CPU and memory consumption). It responds at signal SIGHUP (configuration reload) and at signals SIGTERM, SIGINT, SIGQUIT and SIGABRT (arpalert stops itself)
ArpwatchNG: monitors mac adresses on your network and writes them into a file.
last know timestamp and change notification is included. use it to monitor for unknown (and as such, likely to be intruder's) mac adresses or somebody messing around with your arp_/dns_tables.

https://en.wikipedia.org/wiki/ARP_spoofing


Encrypting an empty database field versus leaving it empty

Since only a minority of the records might contain actual data in that field (non-empty), an attacker can guess the plaintext (the empty ones) with a high probability. So your assumption is correct. Luckily, for you and for us, as far as we know, AES isn't really susceptible to known-plaintext attacks.

The attacks we already know about require large amounts of plaintext and their corresponding ciphertext, and have very high computational complexity (2254.4 for a 256-bit key).

I'd say don't worry about it. Go with encrypting that data field.