Should we prevent this login XSS attack?

tl/dr Your setup assumes that an attacker can't read requests from your server.  This is only true for in-browser requests.  However, a
  login endpoint doesn't use cookies so is not authenticated and
  therefore an attacker has no reason to be making requests in browser.
  As a result a core assumption you are making (that the attacker can't
  read responses from your endpoint) is invalid, and this security step
  is largely useless.    Now that it is causing trouble for your end
  users, you should ditch it all and stick with more common brute-force
  monitoring.  Off-the-cuff security measures tend to create more
  problems than they solve - stick to the basics.  I don't think anyone
  attempts the kinds of attacks you are worried about anyway.  A full
  site DDoS is probably easier, so no one would bother trying what you
  are worried about.

There is definitely some confusion of terminology going around that I think is worth addressing.  Most importantly, you keep using the term XSS but this is not an XSS attack.  I agree, your concern isn't exactly a CSRF attack, but it definitely isn't an XSS attack either.  The reason is because you seem to be under the assumption that such malicious attacks would come from a browser: in a case like this they absolutely wouldn't (which is why this isn't a XSS attack).

This is more than just me being pedantic.  You mention in your original question that about Access-Control-Allow-Origin and other CORS settings, and state that a malicious user could hit your endpoint but not read the response.  Again, this is only true from requests made from a different domain in a browser, but in a case like this there is absolutely no reason why a malicious user would be using a browser.  The only reason you would work from inside a browser is if you are trying to take advantage of a user's cookies for authentication (which is the case for CSRF attacks).  however, this is a login endpoint, which means there are no cookies, and presumably therefore no reason why the attacker needs to be doing anything from inside a browser.  That is to say:

A malicious attacker could use any HTTP client to make these login request, they wouldn't be affected by CORS rules, and would absolutely be able to see the response from your server

As we'll see, this fact invalidates the assumptions you are making about your security, and the end result is that your chosen security step is not actually securing anything.  A malicious attacker hitting a login endpoint doesn't need to worry about pre-flight responses, CORS, access control headers, or anything else, because those are only relevant to HTTP requests made by javascript running in a browser, and they would most likely be using scripting tools making HTTP calls from outside of the browser.

Back to your question

So you have this extra security step in place to (effectively) try to prevent malicious attackers from attempting various DoS attacks on your login page.  You specifically mention these concerns:

  At the very least the attacker can rate limit the users IP address. If
  they target a specific email, they can make it look like a DDOS using
  many (real user) ip addresses and lock out the email. If they have
  access to the network traffic they can even analyse the response
  package size to determine if a login attempt was successful
  (Distributed Brute Force).

As stated, your current step is not actually protecting against most of this.  In particular, there is absolutely nothing stopping a malicious hacker from setting up scripts on dozens of different of ip addresses (even just rent-a-vps from a cheap hosting provider), hitting up your GET endpoint to get an access code, and then (with the same IP of course) hitting up your login endpoint with that access code and a chose user's email address.  This will look like a DDoS of a user's email address (because it is) and from the sounds of it will result in that email address being locked.  They don't need to bother analyzing network traffic to see if the response is successful because they will be able to read the response themselves.  Again, it sounds like you were assuming no responses from your server could be read, but this is only true for browsers, and does not impact HTTP requests from any other HTTP client.

Your security will prevent a malicious attacker from performing a DoS with the user's IP address (which could happen if the attacker can get the user to visit a page that has javascript they control), but that doesn't matter.  At that point in time you are talking about a malicious attacker that is clearly targeting your system and/or users, and as such the attacker will have no trouble figuring out how your login flow works and performing the above attack to lock out an email address or even brute force the password.

All that to say: regardless of whether or not this attack is a general concern on the web, the method you have chosen to defend against it and which is causing trouble for your customers is not actually providing any real protection for your system at all.  As a result, the overall answer is easy:

Ditch this security step and make life easier for your users

You also asked:

  Should we worry about this attack?

The answer is a simple no.  Technically things are rarely yes/no in security, and the answer is always "It depends on the level of risk you are willing to accept and your expected threat model".  However, unless you have reason to specifically expect this kind of attack in the near future, I would say that it is not a concern at all.  I've never heard of such an attack happening in practice.

You should have monitoring to try to detect and block brute force attempts against your login page, and you should tie that protection to IP addresses (the details vary, but in essence it is very reasonable to start blocking repeated failed login attempts for the same ip address).  However, I don't think you have to worry about a malicious attacker getting javascript in front of a user to get them to black-list their own IP address (which is essentially the attack you are worried about).  While that is certainly possible, I don't think I've ever heard of such an attack happening in practice - it would have to be a targeted attack and the gains would be so minimal, I doubt anyone would bother.  If someone really wanted to lock people out of your system they would probably have better luck (and an easier time) just doing a rent-a-DDoS and completely shutting down your entire site anyway.


How files of ransom attacks were decypted?

Crypto is hard to do correctly and this is no different for adversaries. Sometimes they mess up. Here are a few things that could lead to such an event. They are mostly the same that apply for good intentioned developers as well.

Weak algorithm used to encrypt, for instance DES. This can be brute forced to find the right key.

Weak key generated for encryption. Again, brute force helps here.

Incorrect implementation. Reusing nonces, using predictable IVs, etc. This also includes not wiping the memory where the key was stored. This results in key compromise by simply looking through memory.

There is a great article describing the most common crypto mistakes here: https://littlemaninmyhead.wordpress.com/2017/04/22/top-10-developer-crypto-mistakes/

Some mistakes require more resources to exploit so a supercomputer involvement is not impossible, but unlikely I think.

I do not think anyone made a deal with the attackers, however that is certainly possible. What could have happened is that a few transactions may have been performed with the attacker to get more information about the scheme used, and possibly reveal mistakes that can be exploited. The secret government quantum computer is very unlikely. A lot of times the key is computed by your system.

A backdoor may be relevant. But it is highly unlikely that it was placed there by the government. If t was the case it was probably left there by the attacker, like the killswitch of WannaCry.

Passwords and CC data is not in any more danger than it already was. Ransomware does no harm there. If passwords and CC data are correctly handled, they are safe. Just like, there are no decryptors available for "correctly" written ransomwares.

Bitcoins and other cryptocurrencies are not in danger either. They may have been incorrectly used, revealing the attacker but that is not the protocol's fault.


Apache/Linux server, DoS attack from own IP

First thing: find out where do these requests come from. It has to be a local process, nothing else is likely to be able to spoof a TCP handshake on a modern Linux platform (nothing, that is, that would then proceed to waste such a feat on requesting random images).

If there are recurrent URLs, you can shadow them behind a RewriteRule so that any such request will actually trigger a script. In the script you can run additional checks to see whether the request is legit (and you will then output the proper headers just as if it was the image the legit client expects), or if it is one of the bogus requests. Against the bogus request you can log e.g. the incoming port. Armed with that, you can query netstat and find out the process. You can also run ps and inspect all active processes in the instant of the bogus request.

I am quite sure that the culprit will prove to be Apache itself (I once had a "cache priming" script go rogue on me due to a vhost modification - I had forgotten putting the script in crontab - and got really weird symptoms, somewhat like yours, until it all came back to me; but your case feels different).

To further refine the scene while containing costs, you can add PID/TID to Apache's CustomLog. Then you will be able to cross-check the requests received from the Apache child gone rogue.

Another possibility is to determine exactly how these requests are made. If through Apache, this means fopen_wrappers, cURL, socket functions, or maybe shell utilities (these should both appear in ps output and result in a much more massive server overload, though). You can prepare a series of script that will:

gracefully restart Apache without any changes
" " , disabling temporarily one of those functions
" " , re-enabling same

After verifying (just to be sure) that a restart does not fix the problem (if it did, it would be a quite different can of worms), you can proceed to temporarily disable - a couple dozen seconds each, no more - one function after another. Suppose that disabling curl results in the system immediate return to normal: then you could restrict investigations to scripts using cURL, and maybe even wrap the cURL function with a logging wrapper.

In case the guilty party turns out not to be Apache, still you will be able to determine what is doing this; then either reinstall the affected program (even if I find it unlikely for any random anomaly to turn a program into a repeat-HTTP-GET-requestor) or inspect its configuration, ancillary data files, scripts, and so on and so forth, looking for any difference from a known clean installation. Since I don't usually believe in gremlins, I expect for some difference to stand out in the end.


Can an infected phone infect other computers in a network?

A modern smartphone is far more powerful and connected than, say, a 1990s office work-station. There's nothing about it being a "phone" that makes it not a network-connected general-purpose computer. This is also true of many Internet of Things devices. The fact that a WiFi light socket is a light socket doesn't make it any less network-enabled or computationally-capable.

Typically, a private phone won't be on a corporate network unless there is a separate "guest" network meant for that purpose, as Mike Scott describes. Still, a smartphone could attempt an attack from that "guest" network (and it's not like compromising that network wouldn't be a problem of its own), or it could directly attempt to attack WiFi access points used by the internal network. Further, if an employee plugs their phone into their work computer to charge it, this is another vector for the phone to attack the internal network.

Another concern for some organizations is the phone's ability to record audio and video. Here, whether the phone is "infected" or not is less of a concern. Even if you trust the owner of the phone, the recording features can be enabled without the owners knowledge or consent.

If you can imagine how an infected laptop or desktop could cause a problem in such an environment, a phone is only an even more network-connected and discreet platform. In other words, for many reasons a phone is an even better platform for attacks as compared to a laptop or desktop.


Perhaps inject a union?  You will need to know what columns are returned by the base query.  Say you determine that the original query is essentially returning:

SELECT id, productName, productDescription, createdDate FROM Products where ID = 1

You can craft a UNION query that matches the same column structure but queries another table.  Then if you pass in the following instead of 1:
1 UNION SELECT null, userName, userPassword, null FROM users

It will create the following query:

SELECT id, productName, productDescription, createdDate
FROM Products
where ID = 1
UNION
SELECT null, userName, userPassword, null
FROM users

Which basically appends another query that hits the user table and returns username/password.

Ideally this would give you the password because the password would be salted/hashed, but if the exercise is asking you to get the password it probably isn't.  Just keep in mind that in a real world scenario you would salt/hash your passwords to protect against your database being compromised.


File upload attack vectors when file is not saved to disk

A dangerous code present in a file can be ran no matter where the file resides. But if the file is non-exe/script one (like a text) then there must be something else infiltrated to be able to execute the content.

Advanced attacks can store the file pretty much anywhere, run code from there and then remove the initial file. Doing that in-memory leaves a lot less traces compared to saving it to a drive.

If the file is in any type of executable format, then things are easier since nothing else is required to activate the content.

If you do protect yourself against CSV injections (note; make sure not to have Equals to (“=”), Plus (“+”), Minus (“-“), At (“@”) at any cell beginning) you should be fine from that side but that would not prevent someone from putting code in a .CSV that actually looks harmless but if correctly assembled makes up a script ran later. So you should also make sure there's no possibility for something to be in already and able to interpret / run further data. If there is no way for anyone to access anything except doing that CSV upload, then this should not be a vulnerability.


What method could a white-box attacker use to track the deletion of memory / files?

There have been more visible instances of "memory only malware" and I think from a practical perspective you would drive yourself bonkers trying to find that needled in the haystack. What could you possibly look for? Page_Execute_ReadWrite calls? Mutexes? Not only that problem (which calls to look for), but when malware begins hooking into other processes, you would be seeing a lot of conflicting issues with legit processes duped into doing something (false positives) along with trying to consistently analyze running (changing) memory calls, routines, subroutines, opens, closes, etc

So you ask: "how could a malware notice that a delete operation was initiated" and I pose: "this would vary, every malware writer is different, there could never be a static method to do this." An attacker could chain multiple variables to ensure they're always going to run without having to worry about whether someone is going to delete it. E.g.:

(pseudocode)

home=c:\Users\someone\appdata\hidden_folder\here

if [ $home >= 0 ]
   then
       call this other {app, dll, cab, zip, etc}
       run other
fi

"Check to see if I exist, if I don't open something to put me back home"

This would live outside of the active process in another minimal application/call. There would be no need to program it into the malware itself. Sort of like a dropper. A dropper isn't the malware itself, only a means to an end (go out and download the malicious file).


ECC How to exchange signed and encrypted data

To ensure only Bob can read the message, the message must be encrypted using Bob's public key. To prove that Alice sent the message, it must be signed with Alice's private key.

I.e. if you are using encryption in the context of a message between two parties, use of seperate keys for encryption and signing is a necessity.

If the order is reversed, and the message is signed before it is encrypted, then the signature is also encrypted and hidden to everyone except Bob.


Automatically determining whether particular product version is vulnerable?

cvedetails.com offer API access, however I couldn't find any official documentation except for the names of the query parameters. Entries in the database can be filtered for example by vendor, product or vulnerability type.

To get all entries for vendor "Microsoft":

GET http://www.cvedetails.com/json-feed.php?vendor_id=26

To get all entries for product "Exchange Server" & vulnerability "Code Execution":

GET http://www.cvedetails.com/json-feed.php?product_id=194&opec=1


Which forensic techniques should I use to identify intrusion or monitoring of my computer or cellphone

There's a broad spectrum of methods that could be used to monitor your communication.

External Monitoring ("Lawful Intercept")

Your attacker could be monitoring your communication upstream. This could be because they're working with your ISP, or they're sniffing your home network (wired or wireless). You said that your attacker knows things you typed... were you typing these over a clear channel?

Defense against upstream monitoring and local network sniffing: Don't send any communications in the clear. Use only encrypted channels, and use only protocols that provide you assurance that you know who is at the receiving end. The attacker will still see all of your communication, but (assuming the encryption is strong, you don't leak the key, and any passwords are strong) they will be unable to read it.

Defense against local network sniffing: Stop using wireless; disconnect the antenna from your access point, disable wireless in software. For your wired network, inspect your cables. If your cables go through the walls, run new cables between the router and computer that are exposed (visible). You may be able to detect sniffers through various techniques, but it isn't always possible.

Defense against anybody brute-forcing your encrypted communications: (Assuming you're encrypting everything...) Flood the attacker with noise. Through whatever communication channel you're using, make sure that you are always sending something -- random garbage. (It doesn't have to be random, anything will do -- the works of Shakespeare, the text of the tax code, etc.) It should still be encrypted; this makes it so that even if the attacker can feasibly brute-force your communications it is even harder because they won't know which comms are legit and which are noise.

Internal Monitoring (rootkit, keystroke logger)

If your attacker has hacked your computer or phone, there could be a monitoring process that is running and sending all of your keystrokes to the attacker.

Defense against rootkits/loggers: You can run a rootkit detector or anti-malware software to try to find it. If the attack is really clever or uses some new technique, you may not find the logger.

Defense to detect them: They have to get the keystrokes off the machine somehow. Run a sniffer. If you detect outbound traffic that is not yours, investigate it. It may lead you to the process that is sending your keystrokes. As another poster mentioned here, you can jailbreak your phone and run a sniffer to detect any unexplained outbound traffic. This is not foolproof; the logger could be using a covert channel that is not detectable using the common monitoring techniques. Careful analysis of a capture file might reveal a covert channel, but a sophisticated attacker might be using an out-of-band channel or other mechanism that is very hard to detect.

Defense to avoid them on your phone: Ditch the smart phone. Get a "dumb", disposable phone and a prepaid account. Use it for phone calls. Use your (wired) computer (see next item) for Internet commnication.

Defense to avoid them on your computer: Go to the store, buy a USB stick (best if you can find one with a physical read-only switch). From a reliable source, put a bootable copy of your OS of choice on the drive. Switch the drive to read-only. Boot from the drive. (This assumes that you are going to install a hardened copy of the OS onto your read-only drive.) For the most protection, don't access your existing HDD. Wipe it (with every reboot if you're paranoid) and use it as swap/tmp space.

Defense to distinguish between monitoring via rootkit and monitoring via network: Using a clean OS (see above), send a message that you want intercepted from your home network. If the message is intercepted, it is very likely that your network is compromised and not your computer.

Physical Monitoring

If the attacker has placed listening devices or cameras in your home, workplace, or other areas that you commonly use, they could be monitoring you that way. Keep in mind that you could be watched through open windows, or someone could listen through the walls of a neighboring apartment.

Defense to detect this monitoring: (Assuming that you can get feedback on whether particular messages are captured.) Assuming you can surreptitiously disconnect your keyboard from your computer, type something that you want to deliberately be intercepted (in a situation where the keystrokes would not be echoed to the screen). If you find out that the communication was intercepted, you can assume that there's something monitoring your keyboard. Repeat as desired, possibly moving to different rooms. Repeat with the keyboard connected to the computer and characters echoed to the screen, but actual network comms disabled.

If your messages are only intercepted when echoed to the screen, you could be subject to Van Eck phreaking. In this case, you would need to shield your LCD from leaking electromagnetic emissions.

Defense: If you think your home and/or office is bugged, don't communicate from those locations.

Defense: If you think your phone is bugged, get another phone (see above). Never let the phone off your person.

Defense: Hire a specialist to sweep your home for RF bugs. (Or move.) After it is verified clean (or you have moved), apply physical security measures to avoid physical compromise and/or at least have the ability to confidently detect it.

Finally, don't discount the possibility that the person you are communicating with has been compromised. Maybe their computer/phone has been hacked, they are being monitored, or they are otherwise providing with your attacker with info. It's also possible that any servers/services that are relaying messages for you have been compromised and are disclosing your messages.


Some wordlists such as rockyou have these sequences in them, so it won't be that safe against a dictionary attack; since dictionary attacks often don't just include normal English words anymore.

Furthermore some tools (autocrack, keywalker, ...) exist that specifically test for these, and as Chriss Murray pointed out, it lowers your entropy.


Is basic HTTP proxy authentication secure?

HTTP Basic over an unsecured connection exposes the username and password, as you expected. Even over an encrypted connection, basic auth isn't ideal because it exposes the credentials on every new request, which means they're constantly held in memory, you can't revoke a session, and using a secure password hashing function (which should take a good fraction of a second) would be prohibitively expensive.
However, for services where there's no actual resources being protected (no sensitive user account data or control of restricted services) and the goal is just to keep the riff-raff off the proxy, it might be sufficient. Knowing the proxy credentials probably won't give the attacker any ability that they didn't already need in order to capture those credentials, except the ability to use the proxy themselves. Obviously that's bad if the proxy is doing something like access to a corporate internal network - those should be protected by a VPN or similar - but if it's just changing the country your connection appears to come from? Probably not a big deal.


Force browser to use higher security connection

As indicated in this answer, you can blacklist some SSL/TLS cipher suites with a command-line argument. Use SSL Labs client test to see what your browser is currently supporting, then close it and launch it again from the command-line with all the cipher suites you don't like deactivated.

Of course, not supporting some cipher suites may imply not being able to connect with some sites. For a SSL connection to succeed, both client and server must have at least one cipher suite they both support.

Also, 128 bits for symmetric keys are fine. Requiring "the biggest keys" is like buying a truck because you think that bigger cars are always better, and a 40-ton truck is undoubtedly bigger than a car. The next time you have to park your truck or pay for gas, you might somehow modify your opinion...


Practical applications of NIST new password policy

Other strategies would not only be difficult to implement, they might be  counter to the intent of NIST 800-63b. Fortunately, there are multiple blacklisting solutions, so you probably don't need (or want) another strategy.

Here's my reasoning.

First, to summarize from 800-63b, section 5.1, the portion about verifiers (such as passwords) that are directly applicable to checking the quality of the user's password.

Required:

Authenticators (passwords) must be:

Minimum 8 characters

Authenticators also checked against blacklist using "values known to be commonly-used, expected, or compromised" (the core of your question) - at least one of:

Passwords obtained from previous breach corpuses
Dictionary words
Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’)
Context-specific words, such as the name of the service, the username, and derivatives thereof

If found in blacklist:

advise the subscriber that they need to select a different secret
provide the reason for rejection
require the subscriber to choose a different value

By my reading, the intent of 800-63b section 5.1 appears to be:

Prevent users from using blacklisted passwords in the first place
Train the user to understand why the password choices were poor

If this isn't possible via the password-changing interface directly, other strategies would require imposition of those goals via human policy. This would require:

A separate way for users to look up passwords in the blacklist. Since the Windows password-changing interface is dedicated and isolated by design, providing a digital way to do this would be tricky (and printing a book instead would be a usability and maintainability nightmare!)
A way to audit for compliance after the fact (by cracking the passwords using the blacklist as a dictionary). You should be doing this anyway ... but in this case, I believe that it defeats the purpose of the NIST guidance (to ensure that the blacklisted passwords are never used in the first place)

Fortunately, you don't need another strategy, if you only need to do the following:

Verify minimum length. The stock AD complexity requirements allow this already.
Implement blacklisting. There are both commercial (Anixis, etc.) and FOSS (https://github.com/jephthai/OpenPasswordFilter) solutions.

In other words, alternate strategies are not only not needed -- they would be impractical, provide a difficult user experience ... and may not actually be defensibly conformant.


Well the most destructive thing I can think of is del /f /s /q c:\*, which deletes all files on the C drive.

A good way to gain further access is to chain a group of echo commands with append redirects (e.g. echo test >> c:\commands.txt) to write a set of FTP commands into a file, then run ftp -s:c:\commands.txt [host] to run those commands on the server and download an executable. We can then do a final request to run that executable.

In general a command injection is likely to be very dangerous, because it amounts to having the same privileges as the account that runs the vulnerable service. Worse, if you're running an XP-based OS, the task scheduler allows for easy privilege escalation to SYSTEM, via the at command.


Schroeder awnsered this better.
But basically a domain is only considered PII if it’s possible to derive a person from it.
Thereby making it a PII.
Doing this is a really bad idea since the DNS system requires that anyone can cache the data by design.
This means anyone can make copies of the data.
In regards to mail servers. It’s actually really rare that a mail server domain refers to a person, it usually refers to a company.
Also is the email address itself allready PII, so considering just the domain part of it is kinda redundant.


What is the relationship between HTTP response codes and successful execution of XSS attacks?

TL;DR: Successful execution of XSS is unrelated to the response code.

XSS is the execution of attacker injected code at the client side. The HTTP response which includes the response code is created at the server side. The server is not aware that the served content contains any problems (if the server would know this it would not serve it) and thus cannot set the response code based on XSS or not.

In other words: XSS can happen with code 200, 403, ... but just from looking at these codes you don't know if XSS was successful or not.


In what cases people know that I see their stories on instagram or mystalk?

In what cases they will know that I see their stories? For example, can they know (from my google account) that it is me?

Assuming with 'they', you mean your friends, it is highly unlikely they will know it was you unless they would know your IP address and use some sort of analytics to see who visited and from where.
It used to be possible for websites to determine whether a user is logged in to their Google account or not. I do not know if this still is the case, but this was the only information that was possible to gather from Google.


China CCTV System UDP protocol isn't working

UDP is no more, and no less, protected than TCP. It is a transport mechanism, not a security system. We sometimes say that TCP is reliable because, contrary to UDP, it includes provisions for acknowledging received packets and emitting again missed packets, but this is not a "security" reliability; it is only against non-malicious transport errors.

If TCP was used, it would not be intrinsically "safer". When we want a "safe TCP", we use SSL/TLS. SSL needs a "reliable" transport like TCP (because it checks that it received every byte in due order and with no alteration, but does not include corrective actions against transmission errors, only detection). However, there is a variant of SSL which is meant to be applied over UDP: DTLS. Thus, a CCTV system which transfers data over UDP may be secure, if it uses DTLS, in the same sense that a CCTV system which transfers data over TCP may be secure, if it uses SSL/TLS.

I don't claim that your CCTV system uses DTLS; I'd actually be surprised if it did. But I want to point out that while UDP does not provide any security, it is not adverse to security either.

That being said, since the CCTV system is supposed to work over any Internet access, and you would get the pictures with an app on your phone, then chances are that the pictures are actually sent to a server operated by the camera vendor. Indeed, there is a "rendez-vous" between the client (the app on your phone) and the camera, the latter being hidden behind an ISP which may apply a dynamic IP; a third party is more or less needed at some point.

In any case, you'd better trust them... If pictures of your parking lot are considered sensitive, then a reasonable first step might be, perhaps, not to send them to people you hardly know in China. Just saying. The operative word here is not "China" but "hardly know": you are delegating your physical surveillance to a third party, and that is not an innocent move.


Possibility of SQL injection on table name that filters backticks?

There's a few things an attacker could do with that code that you might not want.

If their input is SQLITE_MASTER then they could retrieve metadata.
If their input is databasename.tablename, then they could retrieve data from another database.
If their input is (select load_extension(...) from tablename) they might be able to load an extension.

Or they could run any select query they wanted by wrapping it in parentheses.


How do I compare the safety of a compiled program with optimization flag?

Compiler options can influence the security of the resulting program in several different ways. Generally speaking, optimization can hurt security. However, this is not a reason to always turn off optimizations! For example, if your encryption code is so slow that users disable the encryption feature and send data around in cleartext, that makes security worse.
Undefined behavior
Low-level languages such as C and C++ have a lot of areas with undefined behavior. "Undefined behavior" means that anything can happen, and compilers take advantage of this to optimize code.
There a strong disconnect between the way typical developers see code and the way compilers see code. Often, what looks like an obvious optimization to a developer is hard for a compiler to detect, while compilers may perform optimizations that seem to the developer like it's exploiting a loophole.
A classic example is that optimizing compilers will eliminate redundant checks. Sounds good, right?
if (config == NULL) return ERROR_BAD_CONFIGURATION;
… // code that doesn't modify config
if (config != NULL) x = config->value;

An optimizing compiler is likely to compile that last line as if it had read x = config->value since it knows that config cannot be null at this point. Now consider this:
int *p = &config->value;
if (config == NULL) return ERROR_BAD_CONFIGURATION;
…
x = *p;

config->value promises that config is non-null at this point. Therefore the check config == NULL below is redundant and an optimizing compiler is likely to remove it. So, if config is null at runtime, x gets set to a value that's read from an invalid address, leading to a crash or worse. This is an example where an optimizing compiler makes incorrect code insecure, whereas a non-optimizing compiler would let the program get away with being incorrect.
Turning off optimization usually leads to fewer such surprising effects, but it is not a guarantee. The fix for such "optimization-induced bugs" is to write correct code in the first place, rather than hope that the compiler will figure out the intent of the programmer.
Undefined behavior is not limited to low-level languages. In particular, regardless of the language, concurrency inherently has some undefined behavior, because the order in which things happen is not determined. Race conditions can happen in any language (even without built-in support for concurrency, it can happen via communication between programs). Compiler options usually have little influence there.
Side channels
Some vulnerabilities exploit direct ways of accessing information, for example a missing permission check or a buffer overread. Other vulnerabilities are due to indirect ways of accessing information: side channels. A common side channel is timing, including the timing of indirect events.
For example, on a typical high-end system such as a personal computer or smartphone, the operating system protects programs from accessing each others' memory. However a program may still be able to deduce information from the way other programs behave. In particular, by measuring the timing of memory accesses, an attacker program can deduce which cache lines a victim program is accessing, and this provides information about which addresses the victim accesses in memory. For example, the easy and fast way to implement the popular cryptographic algorithm AES uses look-up tables; if the attacker knows which row of the table the victim is accessing, that can allow the attacker to reconstruct the key.
Programs can be written in a defensive way to avoid leaking information in such ways. This is sometimes difficult when optimizing compilers turn code without obvious leaks into executable code that does have leaks, because the compiler has determined that the program would be faster that way. In this case, an optimizing compiler can make even correct code insecure.
Compiler bugs
Compiler bugs are uncommon, much less common than bugs in some random application. Any decent developer knows that if the program doesn't work, a bug in their own code is much, much, much more likely than a compiler bug. Nonetheless, compiler bugs can happen. The higher the optimization level, the higher the risk of bugs. Most code doesn't benefit from the highest optimization levels anyway: usually -O or -O2 is a good compromise between performance and risk.
Safety features
Some safety features are partly under the control of the compiler. There, the obvious thing to look for is whether these safety features are enabled. These safety features generally don't help to defend against vulnerabilities, but they can make exploits harder. They often don't make exploits completely impossible, but they can make a difference between taking 5 minutes and 5 weeks to craft an exploit, and that can give the developer the time to develop and deploy a patch.
For example, many compilers can generate stack canaries. Stack canaries detect when a buffer overflow happens on the stack and halt the program. To exploit a stack buffer overflow, the attacker needs to limit the size of the overflow so that the canary isn't overwritten or arrange for the correct value to be written in the canary's place, neither of which are always possible or easy.


SMTP security regarding sending username and password

This is why these credentials should only be sent over an SMTP connection secured with SSL/TLS (usually on port 465) or STARTTLS (usually on port 587).  See an example of how this is done using openssl s_client at https://www.stevenrombauts.be/2018/12/test-smtp-with-telnet-or-openssl/


Windows 64-bit Reverse TCP Shell not working

Usually to get reverse shells working the first ports I use are 80 or 443 because even with firewalling set on victim machine these ports usually works. The reason is obvious, that ports are used to surf websites on internet and even on restricted configurations they may be opened. If they are not open you should check for open ports. To do this let's suppose a scenario:

If you are trying to get a reverse shell is because you have some kind of RCE. If you have elevated privileges then you can check the firewall configuration (using iptables on Linux or netsh commands on Windows) and you can open any needed port.

Even if you don't have elevated privileges, you can try to read the firewall configuration to see if there are any ports open on outbound connections. For windows you can check this using commands like this: netsh advfirewall firewall show rule dir=out name=all status=enabled. That will show all outbound rules and then you can try to search for an open port.

If you have a very weird or strange restricted access and you are not able to check the firewall configuration, you still can perform "bruteforce" to check if any port is open for outbound connections. You can first prepare your attacker machine listening in a lot of ports: for j in {1..1000}; do nc -lvnp $j & done and then you can perform a loop on the victim machine trying to connect to your attacker machine. If the victim machine is Linux you can a bash loop using netcat. If is windows it depends on the available software (maybe you have netcat for windows, or openssl or any other tool) and you can perform a batch loop trying to connect to your machine. Then you can check if any port was successfully connected launching a netstat command on your local machine and filtering to see only ESTABLISHED connections, but as I said this is only for very weird environments and is a desperated way to find an outbound open port.

Hope it helps.

EDIT

How are you listening on netcat? do nc -lnvp <port> to avoid dns hostname resolution (the -n parameter) because on your case it seems there is some kind of problem with that.

EDIT2

After checking your comments and your edit on the question, it seems as you said like a security solution is blocking the connection once established. It's not related to firewall stuff. Maybe you can try to encode your payload in order to evade that (maybe is an antivirus blocking it once executed). For that you can try shellter or unicorn instead of using msfvenom. Shellter works well on linux using wine. That solutions are encoding the payloads are very good to evade AVs. Give them a try!


Short living Json Web Tokens (understanding problem of JWT)

JWTs are self describing bearer tokens. You experience the two problems described (stale tokens, invalidation), because JWTs are not designed for this use-case.

I suggest you stick with API keys and store expiry and roles on the backend. It is simple and effective.

If you start blacklisting and querying roles with JWT you will end up in the same place with more complexity.


Security for FTP connection within a server

This sounds like the xy problem.

But before I get into that.....

There are several reasons why FTP is generally disliked. Here, the number one reason will be that passwords are sent across the network in clear text - and hence easy to capture. But the (by default) separate data channel is also a pain to deal with on firewalls. If you are not crossing the network then you've addressed these issues.

But do you know for sure that this will always be the case?

A very simple tenet of Security is that you don't install/run software you don't need. Hence unless the host is already running a XXXX server for a very good reason, then adding one is bad for security.

If we are talking about Unix/Linux hosts, then they almost always be running an ssh server - which gives a lot of weight to favouring sftp/scp over ftp/ftps.

Almost as bad as sending passwords across a network is writing them, unencrypted to your filesystem. for your code to connect to sftp/ftp/ftps it needs a password or a private key. Anything which avoided this requirement would be beneficial to the security.

Which brings us to the real issue...

If your code is unable to read the required files which exist on the local filesystem then your permissions model is wrong. That is the issue you should be addressing.


How to get a SSL Certificate for a public IP

1) Can I use my Public DNS address to get the SSL certificate?

No; to quote this Amazon tutorial,

If you plan to use your EC2 instance to host a public web site, you
need to register a domain name for your web server or transfer an
existing domain name to your Amazon EC2 host.

The "Public DNS address" from Amazon (which looks something like ec2-1-2-3-4.compute-1.amazonaws.com) won't work because you are not Amazon.  You need to get your own domain so that you're authorized to get certs for it.

  2) Are there any free CA's that are known as trusted that I can use to
  obtain a certificate?

StartSSL is the traditional answer for this, but they're under a cloud and probably don't fit what you call "trusted".

LetsEncrypt is another good answer that will probably fit your needs, especially where it's you needing access to your service (and not, say, a wide customer base of varied people and browsers).

  3)I want to use https because the EC2 instance will be handling user
  login. Should I go ahead and use regular http and send information
  that way instead of trying to set up https?

No, there's a hundred good reasons to use HTTPS, and very few good reasons not to.


recon-ng already supports import of external data (by newlines) with the SOURCE variable. SOURCE should be available via most plugins, including the domain ones you are interested in.

Check the wiki -- https://bitbucket.org/LaNMaSteR53/recon-ng/wiki/Usage%20Guide -- which includes information on using the SOURCE variables for data from the local filesystem.

There are also the import/csv_file and import/list modules in recon-ng which will push your data into the recon-ng database.

The method for creating a workspace and using add domains to add domains to that workspace's database can be seen in this blog post -- https://www.stevencampbell.info/2016/10/passive-information-gathering/ -- after which you can see the domains along with IP-address data by way of show hosts. This appears to be the way that you are adding domains, which is one way of doing this.

Once a domain plugin is run, or if a workspace is created and domains are added -- as long as you see your domain via show hosts, then the recon-ng database (usually best performed per workspace) can be modified just like any sqlite3 database. For more information on where recon-ng places these sqlite3 databases on your local filesystem as well as other tips and tricks, see this blog post --https://www.codemetrix.net/practical-osint-recon-ng/


How to Perform Vulnerability Assessment for WCF services

Beyond basic SOAP fuzzers there aren't too many advanced tools useful for pen testing of a WCF service. Since WCF/SOAP is really just a front for the underlying API you've written, you really need a tool to assess the vulnerabilities in your API, which is usually something of a custom nature.

There are tools out there like FxCop which have a very simple baseline for security analysis, but you can't rely on it entirely.

There's a great intro presentation on the OWASP site by Brian Holyfield about pen testing WCF services here: https://www.owasp.org/images/6/6c/Attacking_WCF_Web_Services-Brian_Holyfield.pdf. He lists a couple tools, but they aren't WCF/SOAP specific.


SJCL : convert ascii to a BitArray & compute random numbers

Without looking at the exact numbers, let me give some pointers as to why this is happening:

According to the docs, sometimes it will use some extra bits to store additional information (namely, the actual number of bytes):

  Most of our crypto primitives operate on arrays of 4-byte words internally, but many of them can take arguments that are not a multiple of 4 bytes. This library encodes arrays of bits (whose size need not be a multiple of 8 bits) as arrays of 32-bit words. The bits are packed, big-endian, into an array of words, 32 bits at a time. Since the words are double-precision floating point numbers, they fit some extra data. We use this (in a private, possibly-changing manner) to encode the number of bits actually present in the last word of the array.

  Because bitwise ops clear this out-of-band data, these arrays can be passed to ciphers like AES which want arrays of words.

That probably accounts for the the extra bit that's being appended, and also explains why concatenating two BitArrays will not simply concatenate the word arrays, as you seem to be expecting. If the first one had actually a multiple of 4 bytes, then yes, that's what would happen.
If I remember correctly, SJCL will try to use the crypto functionality of modern browsers to create its random number generator, falling back to a custom made one (which uses mouse movement, keystrokes, etc to generate additional entropy to be combined with a [non-cryptographic] PRNG). That means in modern browser it's unimportant whether you set the paranoia or not. On older browsers (or ones that does not support crypto) then you really must put the collectors to work if you plan to use algorithms that depend on a CSPRNG. I'd help you more, but I've never used that functionality myself, so I can only direct you to the docs.

P.S. US-ASCII is a subset of UTF-8, so you don't need to convert to Hex first and then to a BitArray. Just use sjcl.codec.utf8String.toBits(str). (on second thought, how do you know your text is really ASCII? SJCL [normally] runs in a browser... Better be safe, and make your code Unicode-compliant)


Typically, it's just the last 4 that are shown to the customer, sometimes the first 6.

From the PCI DSS 3.4 Standards

  Never store the personal identification number (PIN) or PIN Block. Be
  sure to mask PAN whenever it is displayed. The first six and last four
  digits are the maximum number of digits that may be displayed. This
  requirement does not apply to those authorized with a specific need to
  see the full PAN, nor does it supersede stricter requirements in place
  for displays of cardholder data such as on a point-of-sale receipt.


Does anyone provide per-user warrant canary

I am not a lawyer and this answer is my opinion
I couldn't find any legal authorities confirming or denying this, and I assume you speak about NSL-related canaries (those issued by courts to parties work differently).
My apologies for a long answer but it looks necessary to explain some background to answer the question.
First, National Security Letters (information seeking with gag orders) are authorized by 18 U.S. Code § 2709. The law allows the following:

(1) Prohibition.
— (A)In general.—
If a certification is issued under subparagraph (B) and notice of the
right to judicial review under subsection (d) is provided, no wire or
electronic communication service provider that receives a request
under subsection (b), or officer, employee, or agent thereof, shall
disclose to any person that the Federal Bureau of Investigation has
sought or obtained access to information or records under this section

The prohibition here is very specific, and it is very easy to formulate the canary the way that it does not disclose this.
However the situation with the individual user private key is different since it falls under communication monitoring, and is covered under 18 U.S. Code § 3123. Its (d)(2) contains the following prohibition:

the person owning or leasing the line or other facility to which the
pen register or a trap and trace device is attached or applied, or who
is obligated by the order to provide assistance to the applicant,
not disclose the existence of the pen register or trap and trace device or the existence of the investigation to the listed
subscriber, or to any other person, unless or until otherwise
ordered by the court.

Here the disclosure prohibition is explicit, and disclosing to the user the existence of a monitoring of their communication by means of compromise of their key would be clearly against the law.
Please also see this article if you're interested in the exact legal details how canaries work.
Update: this article confirms the above reason, explaining:

Such a practice would alert users who become targets of investigations
and cause them to withdraw their business from the company, thereby
jeopardizing legitimate inquiries into individuals who pose actual
threats to national security.

and

Granular canaries have the greatest potential  to  compromise
legitimate  national  security  investigations because  they  could
alert  the  target  of  an  investigation of  the government’s search,
prompting that individual  to cease use of the targeted  service,  and
to attempt  to erase  his  or  her  information therefrom. Clearly,
the government has a strong interest in preventing this outcome. Thus,
courts are less likely to find that these canaries are legal and are
more apt to uphold a gag order prohibiting their removal.


What asymetric scheme provides the shortest signature, while being secure?

You cannot have a secure signature scheme in less than 50 bits. Demonstration: the attacker can just enumerate all sequences of 50 bits until a match is found. Indeed, one point of digital signatures is that the verification algorithm can be computed by just everybody, since it uses only the public key (which, by definition, is public).

Best you can hope, theoretically, is a signature of n bits for a security of 2n. Traditional threshold of infeasibility was n = 80 bits, but the relentless advance of technology tends to raise that. Modern cryptographers tend to jump to 128 bits, because that's a power of two, hence beautiful (Kant notwithstanding, most aesthetic judgements are relative). 100 bits ought to be safe for quite some time, though.

Among known signature algorithms which are believed to be secure, BLS is right now the best in class; it will produce signatures of size 2n bits for a security level of 2n, so you are contemplating signatures of size 160 to 200 bits at least. There are algorithms which can go below (down to about 1.4*n) but they have a rather long history of breakage and fixing and breakage again (I am talking about SFLASH and its ilk), so their use is not really recommended, and there's no directly usable standard.

Another possibility is to use RSA with ISO/IEC 9796-2 padding. As the linked article shows, there are some subtleties with regards to its usage. This signature scheme is a scheme "with recovery" meaning that while the signature is rather bulky (1024 bits if you use a 1024-bit RSA key), it can also embed some of the data which is signed; so, if your problem is about appending a signature to a message, then this scheme will induce relatively low overhead. As the article explains, you get 261 protection for a signature overhead of 22 bytes, aka 176 bits; to get good security, you would have to use a hash function with an output size of, say, 224 bits, leading to a signature overhead of 240 bits -- not as good as the 200 bits of an equivalent-strength BLS, but better than the 400 bits of DSA or ECDSA (for still the same strength level).


Verifying that no malicious certificate has been issued while a DNS record was pointing to an uncontrolled IP

TL;DR: Yes, checking for that domain in any public CT Log viewer and finding only certs that you bought will give you pretty high confidence that no malicious certs were issued to that domain.

Yup, I totally agree with you that an attacker could have gotten a VM at that IP and that would have been sufficient to get through the automated domain validation checks and gotten a cert. You talk about the attacker getting a cert from Let's Encrypt, but unless the victim had set up a DNS CAA record for their domain:

CAA records allow domain owners to declare which certificate authorities are allowed to issue a certificate for a domain.

then the attacker could get a cert from any CA, and some CAs offer certs with lifetimes up to a year.

Solution: *Superhero music blares* Certificate Transparency to the rescue!
The catch with CT is that some browsers enforce it and others don't, there is no global requirement from the CA/Browser Forum that CAs log to CT.

Chrome (and I think also Chromium) strongly require CT logging on every web site cert since 30 April 2018 or the browser will throw errors (source).
Safari looks like they are starting to require it, though that's news to me and that page is dated Mar 2021 (source).
Firefox does not require or check CT logs (source).

That said, I can't imagine that there are any major CAs who do business by only being in the Firefox root store and not Chrome's or Safari's, so it's a pretty safe bet that all majar CAs CT log every cert they produce to Google's standard.

Summary: Yes, checking for that domain in any public CT Log viewer and finding only certs that you bought will give you pretty high confidence that no malicious certs were issued to that domain.


To answer the first question: no, it is not possible for one socket without connecting to it, unless you attack the IP layer underneath. In that case you don't have to talk about sockets anymore.

No, it is not safer to have a server socket connect back to the client. An attacker could send the server socket almost anywhere.

If you want to protect a socket, use TLS.


Securely remove data from hard drive without killing recovery partition

Disks do not always map a logical address to the same physical location, especially SSDs. When a remap has happened, the physical location with data may not even be accessible to user programs like DBAN. Specialised make/model-specific tool will be required and they most often can only do full wipes.

So the only real safe solution is to clone the recovery parition to a new drive and destroy the old one. Of course whether you do this depends on how sensitive/valuable the data is and what kind of potential threats you want to defend against.

A more economical workaround is to clone the recovery parition (and partition table/MBR) to another media, fully wipe the original using the correct tool and clone the partition back.


How to determine if someone is scanning my server?

Is your system publicly accessible?

Yes: Someone is probably scanning it.
No: Are you scanning the server?

Yes: Well, you've just answered your own question now haven't you?
No: It's probably not getting scanned.
I don't know: Wait... what?

I don't know: You've got bigger problems. And yes, you're probably getting scanned.


How to test CVE-2004-0789 Multiple Vendor DNS Response Flooding Denial Of Service?

The basic Nessus test appears to be replicable  by using a hex editor to create a response file ( I used the Nessus google example) and then sending that data to the target DNS server via netcat:

so:

 od -ah dns-response-dos.txt

0000000   `   x enq etx nul soh nul nul nul nul nul nul etx   w   w   w

f860    8385    0100    0000    0000    0000    7703    7777

0000020 ack   g   o   o   g   l   e etx   c   o   m nul nul dle nul soh

6706    6f6f    6c67    0365    6f63    006d    1000    0100

0000040

...and then:

cat dns-response-dos.txt | nc -u "target dns server"  53

`���wwwgooglecom^C

..produces a response.

Garbage data produces no response


Tracing security policy permissions in JavaScript

Access-Control-Allow-Origin:* allows certain CORS requests from XHR, but does not allow direct JS acces through the iframe.
If you want to use communicate with the iframe you could use postMessage instead, and implement listeners in both the iframe and the parent. Of course you then need to control the page shown in the iframe.


You can use "burp" as a proxy which would enable you to see all http packets that you are receiving and sending.

It is pretty simple to use and works with pretty much everything. You can even edit/drop/resend packages.


What is a secure way to use PHP tokens in a C# application

It sounds like you, as many before you have done, are trying to make it so only an "authorized" client can access your online API (presumably a web service). This, as you suspected, is impossible. You can take many steps to make it harder for somebody to write a functional unauthorized client (obfuscation, encrypting the tokens locally, blocking the use of an intercepting proxy by employing certificate pinning, various other DRM schemes, etc.) but at the end of the day, if you give users a working client, they can (and, if they have any reason to bother, will) duplicate everything that client does so that your server thinks it's legit.

The bigger question is, why do you care? There are generally only a few reasons people try to prevent unauthorized clients:

They are putting too much trust in the client. An example might be an online game where the client tells the server whether or not the user won, instead of the client telling the server what the user did and the server deciding who won. Never trust the client.
The service is expensive to use in some way (monetarily, computationally, storage-wise, whatever) and they want to limit how frequently requests can be made to it. The correct approach here is to require authentication of the user, rather than the client, and either charge the user or limit the number of requests they can make.
They don't want people automating interaction with the service, for example because it's a game with a lot of repetitive behavior and they don't want people writing bots for it. In that case, tough. There's only so much that can be done against this, and it usually comes down to some kind of human review of replays or something like that to detect cheaters.
They want to only support specific users (for example, they don't want to bother with a Linux app) and are worried that if somebody ports their app then they'll get bombarded with support requests for code they didn't write. Honestly, there's no good way around this one (aside from trademarking your service name and using legal threats against anybody who tries to publish something as you, but that doesn't stop them from publishing something that is "an unofficial YourService(TM) client").

If it's something else, please add the relevant info to your question and I'll address that. Overall, though, it cannot truly be done. You cannot give somebody the key to a door but prevent them from copying it or sharing it.


Summary: Don't do it.

Your question is mainly about anonymity. So I'll address that first:

You are talking about buying three pieces of hardware and two SIM cards. Each of these have an identification, which could possibly be tracked back to time and location of sale. At that point it could possibly be tied back to a CCTV recording or a card used to pay for the purchase.
There is also the possibility of a CCTV catching you in the act of hiding the device.
Finally you would want to communicate with this device. Both the ISP that you use to get in touch with this device as well as the ISP you use to establish connection to the device will likely have records indicating which pair of IP addresses are communicating.
There are plenty of ways in which the association between the two 4G dongles could be established. First of all you might have bought both at the same time, secondly the provider will know the approximate location of both dongles which happen to be the same and hardly ever changing.

As for the legality there are multiple reasons why what you are asking about might be illegal:

You might be violating trespassing laws when installing the device.
Even if you are allowed to be in that location, you might not be allowed to leave any of your personal belongings behind, when you leave that location again.
Hooking into an AC line without permission is almost certainly illegal and could potentially get you electrocuted.
You may be liable for the disruption caused by evacuation of the building and the bomb squad sent in to remove the device if the first person to find it does not have a clue what it is.

The reliability of such a device is unlikely to be good:

There is the possibility of the network access provided by your SIM cards to go through a CGN which means connecting to this device remotely can be difficult or even impossible.
If you were able to hide it in a public place there is the possibility that somebody else could find your device and modify and/or steal it.
If you ever return to the device in order to service it, there is no way of knowing who might be waiting there for you. (But they will probably suspect you to be a terrorist.)
The connectivity of either 4G dongle or the power supply could change in unanticipated ways with no warning.


Should hard drives be encrypted prior to an operating system installation?

In principle, it can be done both ways, just one is more complicated.
Namely, directly:

Wiping if there was sensitive data before (eg. with dd on a spinning HDD, or the builtin Erase feature of SSDs)
Installing the OS and choosing to encrypt the partitions there
Done

or

Installing the OS
Making a full backup to another medium
Using a LiveCD etc. to wipe the first hard disk
Create encrypted partitions there
copy the files back to the new encrypted partitions
Fix bootloader etc.
Wipe the second hard disk (the one that was used temporarly for storing the backup)

And it depends on the specific software that is used.

LUKS on Linux can be used during the installation already (depending on the distribution at least)
(not sure about Bitlocker on Windows right now)
Veracrypt (I don't recommend it for such things): neither Windows nor Linux support it out of the box, and of course it's not supported in their installer either. Still, encrypting the OS partition manually later appears to be possible now (at least for cases that are not too complicated), with some third-party tools.
...

For "method of encryption", the default settings of LUKS etc. are fine (nowadays it's AES-XTS and so on).

And for the benefits on hard disk encryption, there are probably more complete answers out there, but in short: If the laptop is stolen and turned off, nobody can see your secret files. It does not help if the laptop is turned on. And if it was stolen and you get it back, you can't trust it even if it was encrypted.


Should I change to VeraCrypt on win7 SSD from TrueCrypt 7.1a?

NO. It is NOT safe to use Truecrypt, which was last updated 4 years ago.

Two CVE's exist but there could be more because Truecrupt is no longer in the interest of security researchers anymore.


In what ways can the contents of RAM be (inadvertently) written to disk?

Program crashes save minidumps that contain some parts of the process memory, including thread contexts, some active pages, the stack, etc.

The solution for all of these, though, is to use full-disk encryption (FDE). That way it doesn't matter what data is written to the disk - memory dumps, logs, cached files, etc. - they're all encrypted at rest anyway.

If you've got particularly sensitive operations that must never touch disk, the usual way to go is to have a read-only storage medium and boot from that. Unfortunately, Windows doesn't like that and generally will not boot without a writable root NTFS volume. Instead what you can do is build a machine with sufficient RAM to install Windows to a RAMdisk, perform whatever volatile operations you need to, then unmount the RAMdisk and all the contents are permanently lost. RAMdisk tools can also use AWE to force memory to be marked as physical-only, so it can never be paged out to the swap on the host system. You only need about 48GB of RAM to do this, although 64GB gives you a bit more headroom for mounting a ~32GB volume and running the base OS and guest VM.


If someone gets my Routers Device Access code can they remove the firewall settings?

Yes but the following has to be true:

They are on your LAN, i.e connected to your network (Wifi, ethernet etc)
They can get remote access to your network. E.g Many routers have a remote access protocol, make sure to disable it or if you really need it make sure to have a great password. Take steps to secure your router generally, (disable UPnP etc) to block all remote access points.
You have a vulnerability in your router. This is very common, keep your firmware up to date, check online to see if your router has any un-patched issues.


Using VPN may secure the connection between your device and vpn server but its not enough. Not using vpn may be more secure than using a public one, you shouldn't trust a unknown machine.

Building your own VPN server on a droplet is something you can try. I'm using SoftEther VPN Server for that and I can suggest that to you. It has a nice GUI administrating panel for Windows, after installing it to a droplet you can use graphical interface to manage it simply. It also supports many protocols, nearly all of them! You can connect it via OpenVPN, L2TP with IPsec, SSTP etc. It also has its own client that supports ICMP & DNS hole punching and VPN over SSL that allows you to connect from vpn-restricted networks with high speed.

Digital Ocean Community has a tutorial for setup:
How to Setup a Multi-Protocol VPN Server Using SoftEther

By the way: If you use DigitalOcean to build your own VPN server, after everything is done you can take a snapshot of your droplet and destroy your droplet. Whenever you need some security, all you need to do is creating a droplet from existing snapshot, the snapshot that you took last time. IP address of server may change but the server will stay up and running. By doing this you only pay for hours that you actually use.


How to implement "Enter Password to Continue" for a page in a stateless application which uses JWTs?

The easiest way is to perform both the task in question and the authentication in one go. Let the user fill out any forms and enter the password at the same page. When the user submit, you check that both the JWT and the password are correct server side, and if so execute the task.

This works well for tasks that don't require a lot of user input, like changing your email. For something bigger, like giving access to a full admin area, you need something else.

Lets look at the admin area as an example. One solution is to have a separate login endpoint for the admin area, and after authenticating the user at that endpoint you just add a flag to the JWT payload, e.g. isLoggedInAsAdmin: true. If you want to have the logg in for the admin area expire quicker than the regular logg in you can just use a separate JWT instead.


It's probably justified, because with the speed of which computing power increases, older encryption quickly become weak, what once was considered "too hard to break" becomes feasible.

Apple do have the habit of educating their users / developers, which also tend to be lazy and neglect such issues, so this is probably a good thing, especially when solutions are easy to implement.

There are some cases in which ATS has to be disabled, but most times it can be fixed without disabling ATS -

A) Backend doesn't support HTTPS connections

Configure your backend to support HTTPS connections, there's no reason to use non secure connections.

B) Backend is using a self signed certificate

Either sign it with a know Certificate Authority, or pin your self signed root certificate. You can use AFNetworking to pin your CER file.

C) Backend doesn't support TLS v1.2 with Forward Secrecy

Update your server to support those ciphers. Search the web on how to do this on your web server.

D) App communicates with a 3rd party that doesn't full comply to ATS

Add an exception for that specific website. Check if the endpoint supports HTTPS scheme, TLS v1.2 protocols and Forward Secrecy cipher suites, if any of those are missing - and a specific exempt.

If they don't specify which API endpoint they use, you can use a sniffer like Wireshark, or other winpcap based program to find out who the 3rd party library is communicating with.

Here's a great guide on setting exemptions -
http://ste.vn/2015/06/10/configuring-app-transport-security-ios-9-osx-10-11/

E) App opens an unknown external URL

Use SFSafariViewController to open unknown external websites. It encapsulates all protection measurements required to protect your user.

F) App has an inline web browser

This is a bummer, since SFSafariViewController uses a modal view and you probably need to use UIWebView, which follow the ATS rules of your app. There's no way to allow HTTP connections on a specific UIWebView control.

If you want to support opening HTTP website from an inline UIWebView browser, you'll have to enable NSAllowsArbitraryLoads.


Hops encountered More for spam Mails than Legitimate Mails

This is probably correct in a statistical sense. A legitimate e-mail will probably (but not certainly) go through several hops not only on the destination side (which are mostly always the same for a given recipient, so that number is not interesting) but also on the sending side, and these will be recorded in Received headers.

A spam, however, while sent by a relay, is often sent by a non-smtp relay or by a trojan on an infected PC. These vectors will not add Received headers. The spam will only have Received headers if it is relayed through a legitimate server (there are several advantages and disadvantages to doing that, it is not a very common choice as far as I can see) or if the spammer wilfully adds fake Received headers in an effort to confuse people or anti-spam programs that try to analyze the headers (and that is passably common).

So, statistically it does not surprise me that spams on average have less Received headers than legitimate mails. However, apart from adding this to some Bayes filter criteria in a sufficiently low-profile way that the major spammers out there do not start adding masses of fake Received headers to their junk, I don't really see a way you can make use of this insight.


What risk does commoditized dedicated SHA256 processors pose to IT Operations?

Such hardware may make life more difficult for people who rely on PBKDF2 for password hashing. Password hashing functions are intentionally slow -- slow for the honest server and for the attacker alike. We want it to be as slow as is tolerable for the server which uses it, so that it becomes (hopefully) intolerably slow for the attacker.

The defendant's advantage in the password hashing game is the password complexity. The defendant wants a function which can be used to verify one password at a time, whereas the attacker must try millions or billions of them.

The attacker's advantages are:

Patience: the attacker can afford to spend two weeks cracking the password, while the defendant must verify a user's password within one second (users have no patience).
Money: the attacker's budget for hardware can exceed that of the defendant.
Parallelization: the attacker has many passwords to try and thus can fully benefit from hardware which can do parallel computations (e.g. clusters, GPU, or simply a bunch of PC momentarily "borrowed" from a University, in case the attacker is a bored student).
Specialization: the attacker can invest in specialized hardware (such as the ones you refer to) and thus get more hashing done per dollar invested than the defendant (because the defendant uses a server which must also do something useful besides verifying the passwords).

Specialized hardware which is good at SHA-256 is thus an advantage for the attacker, if the password hashing function uses SHA-256, of course. Some other password hashing functions (e.g. bcrypt and, even more so, scrypt) are more GPU-resilient and will offer a somewhat better protection, as long as nobody begins to mass-produce specialized bcrypt-cracking hardware, of course (e.g. the Virtex family of FPGA from Xilinx, which have embedded RAM blocks and can thus compute bcrypt quite efficiently). See this answer for a more detailed discussion.

Note that while SHA-256 specialized hardware makes it theoretically easier to attack SHA-256 upfront (building collisions, computing preimages...), the work factor for these attacks is still far away in the unfeasible zone. See this answer for some analysis.


What's the difference between "load testing" and "stress testing" within the context of a security audit?

There's a few different definitions, however the one I go with is that Load Testing is taking an application up to its expected maximum load level to make sure it performs. Stress testing is deliberately taking an application past its normal parameters to see how it tolerates a greater than expected load. It's sometimes called torture testing, seeing how an application breaks.

From a security perspective you should always care about the security implications. No matter how much load an application is exposed to it should always follow its security parameters, or if it is going to fail, fail safe.


Why should I separately backup my revoke certificate

You can backup your revocation certificate to a more reliable, but less secure place (friends, relatives); losing it is just an annoyance. You probably wouldn't do that with your private keys, losing them is a catastrophe (or major problem, as you described it).

Just storing to multiple devices does not seem reasonable. Maybe this argumentation is usually a little bit constructed, but who knows? Police might seize all your devices, a GnuPG library bug might affect all stored keys at the same time, ...

As there are few disadvantages and low cost for doing so, there isn't really a reason against.

  Do you see any such media, or are any of my assumptions wrong? Why and where do you store your revoke certif on its own?

I store my revocation certificate (apart from a digital version, which is backed up digitally) on a piece of paper: qrencode is a great thing, just don't forget to add a note what this is and how it was created. And verify you can read it, I was having problems using some readers. A revocation certificate fits rather well on a DIN A4/letter format piece of paper, and could even still be read using smartphones.


What are vendor affirmed algorithms in FIPS 140-2

This is a bit of a guess, but on page 6 of the Derived Test Requirements for
FIPS PUB 140-2, we have (emphasis mine):

Required Vendor Information
VE01.12.01: The vendor shall provide a validation certificate for all Approved cryptographic algorithms.
VE01.12.02: The vendor shall provide a list of all non-Approved security functions.
VE01.12.03: The vendor shall provide a list of all vendor affirmed security methods.
VE01.12.04: The vendor provided nonproprietary security policy shall include reference to all vendor affirmed security methods.

It sounds like, during a certification, they're breaking crypto implementations into 3 categories:

Approved cryptographic algorithms: implementations that have already been certified (that you use internally). These will be excluded from the review.
non-Approved security functions: if you really want to use MD5 or twofish, or some other non-FIPS crypto, you need to declare it. These will be excluded from the review.
vendor affirmed security methods: things that the vendor claims conform to the spec, but have not yet been verified by NIST. Presumably this is what you are submitting for testing.

So as for your question:

Can I say my AES implementation as vendor affirmed and get it added to the FIPS certificate?

Of course! You are perfectly welcome to run your AES implementation through the CAVP and get it FIPS certified (if it passes, of course)


Same-origin policy for file: URLs in Android browser?

When you execute a .html file using the file:// URI  that script is run in the "file" zone. Which means that you can read files on the local file system using an XHR. (This is subject to change,  and is also easy to verify)

As with most "standards"  it depends on what browser you are using. If you are using Firefox on any system,  including android, JavaScript can only access files in its own directory and all sub directories.  But this is a recent change FireFox's SOP (May 1st 2012).

WebKit is a different story. If you have a script running in the file:// zone then you can read any file on the local file system,  so long as the browser is running as a user with the necessary file permissions (/etc/passwd should always be world readable).

It should be noted that most browsers will not allow you to redirect from a web zone (http, https) to the file zone. Once upon a time you could do this,  but it was a feature that was ripe for abuse.  So if there was a DOM based XSS vulnerability in a local .html file it would be difficult exploit (I am not aware of a method of doing this, and this method would likely be a vulnerability).  Although this theoretical vulnerability maybe "cross-zone scripting"  which would allow an attacker to exfiltrate files off of the local file system,  it would be very difficult to exploit due to redirection restrictions.


Could YouTube downloaded videos be infected (by Youtube)?

To answer your 4 questions :

Could (downloaded) Youtube videos be infected?

Technically, yes, even if it is quite unlikely. In such a case a malicious video could infect you if it targets a specific player (and possibly a specific version). In such a case, a malicious actor would have uploaded a video in the hopes that someone downloads it and then plays it with a vulnerable version of a specific player.
Please note that technical treatments occur on Google's (Youtube's) side - such treatments could easily destroy the malicious content.

Could Youtube infect them to punish illegal downloading?

Technically, yes, but that would be illegal

I removed the add-on - should I delete those videos too to be safe?

To be lawful (and have morals), you should delete the videos for which you do not own the rights, if the videos you downloaded are protected. However if we are talking about being technically safe from infections, as mentioned in a previous bullet the chances that the videos contain working malicious code are slim. If you want risk-zero, delete them, even if the chances are very low

If I use AVAST, Emsisoft Anti-Malware, Malwarebytes and SuperAntispyware Free Edition, will I be safe and find anything there is?

Not necessarily. AV's cannot detect everything.

As comments pointed out, it is good to note that the add-on that you used could have triggered an infection. It is always a good idea to be very careful when downloading browser add-ons / extensions, especially if they are used for possibly illegal purposes (which means that there is a slightly higher chance that the add-on author is malicious)


Is ignoring a threat you cannot defend from a valid strategy?

You would never ignore a threat, and perhaps that is semantics over your wording. You either accept, mitigate, or outsource the risk for the given threat.
In this case, that would be:

accept that there will be a $X loss,
mitigate fix DRM or find DRM alternate to protect the product, or
outsource using insurance or place the risk on someone else in the same way insurance does.

In your case, if 1) is not acceptable then they need to move to 2 or 3 as their alternatives.


Many applications make futile attempt to foil keyloggers and spyware by using convoluted (and cumbersome) password entry methods. None work against keyloggers and many actually cause users to be LESS secure because they make it hard to use password managers.

The best way to handle that kind of things is to use one-time passwords. There are several ways to go about it so let me suggest two: TOTP (RFC 6238) works with many software authenticators (Google authenticator, for instance) so it's both convenient, cheap to implement and free to use. It does require the user to set things up and have a smartphone, though.

Another approach it to send a one time password through SMS. This is a bit more expensive (because you have to send the message) but it's also easier for the user (who only needs a mobile phone and no setup).


What is the practical difference between MAC and Capabilities

The short answer: They are two entirely different kinds of systems.  They're just different.  Comparing them is a bit like comparing apples and oranges.  They are so fundamentally different -- different in so many ways -- that no one-sentence comparison will really do them justice.

Oh, that's not good enough for you?  OK, then, here's the long answer.

Background: mandatory access control.  In my view, the entire notion of "mandatory access control" (as opposed to "discretionary access control") is incoherent.  Access control systems are always mandatory; the whole point of an access control system is to enforce some access policy on subjects.  Compliance is not voluntary; subjects are forced to abide by the policy, whether they like it or not.  So the entire notion is confused; any access control system always include mandatory elements.

That said, many people use the phrase "mandatory access control" to refer to a class of approaches to security, based upon military-style classification and information flow control.  Mandatory access control systems often introduce some hierarchy of labels -- a simple example might be "Public", "Secret", and "Top Secret", or "Low" and "Hi" -- and tag data with these labels.  The system then enforces some rules to ensure that anything that's derived from confidential data will also be treated as confidential; these rules typically enforce how labels are assigned and updated as information propagates throughout the system.  A typical goal would be to ensure that Top Secret-classified information can never leak out over an unclassified channel

(Strictly speaking, this is a "multi-level security" (MLS) systems; while MLS systems are a form of mandatory access control, one could also imagine hypothetical mandatory access control systems that don't use MLS.  However, because MLS systems are the classical example of a mandatory access control system, "multi-level security" often gets conflated in many people's minds with "mandatory access control".  At risk of causing confusion, I'll continue to use the phrase "mandatory access control" to refer both to the general concept as well as to the particular notion of multi-level security, because this is how the term seems to be used in the literature.)

Bell-Lapadula is an example of a theoretical model that is often considered representative of the mandatory access control approach.

SELinux is sometimes classified as a deployed system that implements mandatory access control, but this may be a bit misleading.  SELinux has at least two configurations.  In the strict configuration, SELinux enforces information flow control rules to every process running on your system.  However, this is too strict for general use.  Therefore, this is not how SELinux is deployed in practice.  In practice, the Linux distributions that have adopted SELinux have instead deployed it in so-called "targeted" mode.  For most intents and purposes, targeted mode limits only certain applications (there are a few global rules that apply to all applications but they are very narrow).  Targeted mode consists of a set of ad-hoc rules about what kinds of information flow and accesses those applications can do.  It only places restrictions on a subset of applications, and those restrictions are partial.  It does not try to provide comprehensive security.  It does not try to ensure that, e.g., Top Secret-classified information can never leak.  Therefore, SELinux -- as it tends to be deployed today -- is a watered-down version of mandatory access control that falls short of what the original proponents of mandatory access control envisioned.

Object-capability systems. Object-capability systems are an approach to enforcing authorization policies.  The core precepts are: access to a particular resource is granted to those who hold a corresponding capability (and only if the capability is held); capabilities can be freely passed from one subject to another; and capabilities are the only means by which access can be obtained.

Object-capability systems are designed to solve a particular problem.  The design goal is that the OS should provide a very limited, simple substrate for expressing access control policies.  Thus, the OS provides a few very basic primitives (the ability to use a capability, the ability to pass a capability on to another subject), and nothing more.  What about applications that need to enforce rich access control policies?  Rather than building support into the OS for each individual little thing that some application might want, in an object-capability system the application is empowered to implement its access control needs using the basic primitives provided by the OS.  This keeps the interface exposed by the OS simple, while still preserving flexibility and enabling applications to express and enforce complex access policies.

Beware: "POSIX capabilities" are not capabilities. If you'll allow me to take a tangent, I'd like to inject a note of caution.  You may have heard of POSIX capabilities.  This name is unfortunately and poorly chosen.  They are not, in fact, capabilities at all.  Rather, the OS identifies a set of a dozen or so special privileges that are typically granted to root in a conventional Unix system, and allows processes to be granted a subset of these privileges.  However, they are not held by processes as a capability, and there is no notion of passing them from one process to another.  In other words, despite the unfortunately-chosen name, they aren't capabilities at all.  Therefore, to prevent confusion, I'd like to exclude them from this discussion entirely (unless you tell me that "POSIX capabilities" is actually what you were interested in learning about).

Comparisons. Let me draw some comparisons and contrasts between mandatory access control and capabilities.

Confidentiality?  Traditionally, mandatory access control systems have focused on enforcing confidentiality restrictions: e.g., ensuring that classified-Secret data is never leaked to anyone without a Secret clearance.  In contrast, object-capability systems usually focus more on integrity and access control.

One reason for this is covert channels: no access control system can eliminate covert channels, and covert channels allow two colluding parties to conspire to defeat the purposes of traditional mandatory access control systems.  If Alice has clearance to access the secret data, and Alice is conspiring with Bob, then Alice can arrange to leak the data to Bob, no matter what any access control system tries to say about this.  Object-capability systems recognize this and don't try to prevent it; they subscribe to the slogan "Don't prohibit what you can't prevent".  Mandatory access control systems try to prohibit this, even though they can't prevent it, and published work on mandatory access control is often evasive about covert channels or ignores the problem entirely.
Feasibility?  Unfortunately, traditional mandatory access control policies -- while appealing in their elegance -- have turned out to be not very practical.

The primary challenge is the phenomenom that "eventually everything floats to Top", meaning that eventually almost everything in your system gets labelled with the top-most confidential label: e.g., Top Secret.  Why?  Well, imagine a spreadsheet containing some Public data and some Top Secret data.  It will get labelled Top Secret.  In general, any time you perform any computation that depends upon both secret and non-secret data, mandatory access control systems will label the result as secret.  If Alice sends a non-secret message to Bob, and Bob is labelled secret, and Bob returns an acknowledgement back to Alice saying that he received her message, then mandatory access control systems will often label Alice as secret (this is intended to capture the fact that the acknowledgement might convey secret information from Bob to Alice).  So basically any time that secret data mixes with non-secret data, it all gets labelled secret, and any time that a subject with access to secret data interacts with a subject with only non-secret data, they both get labelled secret.  This acts as a one-way ratchet that causes more and more data/subjects to be labelled as secret.  People have observed that, over time, most or all of the system eventually gets labelled as secret, and then the system becomes useless to non-secret users (you might as well have just said that this system is only intended for Top Secret data).  This renders mandatory access control systems less useful than one might expect.  As a result, traditional-style mandatory access control has seen little deployment.

Modern mandatory access control systems do try to avoid this problematic phenomenom, by introducing various variations to the basic MLS concept listed above.  (For instance, SELinux's targeted mode avoids the "everything floats to Top" phenomenom, by avoiding trying to provide comprehensive information flow protection for all confidential data.)  However, these variations on the traditional mandatory access control concept tend to introduce their own problems:
Complexity?  In principle, both mandatory access control and object-capability systems are built upon a simple and elegant theoretical foundation.  However, in the real world, mandatory access control systems are typical forced to depart from this elegant foundation if they want to avoid the "everything floats to Top" phenomenom.

As a result, deployed mandatory access control systems -- like SELinux -- tend to be extremely complex.  Even in its targeted mode, SELinux's access control policy specification runs to something like a hundred thousand lines of access rules.  This makes the system hard to understand, when something goes wrong.  SELinux is notorious for causing hard-to-debug failures in some use cases, and on Linux distributions that use SELinux, you'll often see people suggesting that users try shutting off SELinux if they run into a hard-to-diagnose system administration problem.

So far, object-capability systems as implemented retain much of the elegance and simplicity of their theoretical foundations, so they don't seem to suffer from this complexity problem as much.  However, we don't have as much practical experience with object-capability systems, so it is hard to know for sure whether this early experience will hold up.
Who sets policy?  In mandatory access control systems, usually it is envisioned that some omniscient and benevolent system administrator will establish the access control policy that everyone must abide by.  However, in practice, this can get really annoying.  I'm sure we've all had the experience where some firewall or security system prevents us from sharing data with someone else, or some company security policy makes it hard for us to grant access to someone we're working with.  What do you do when that happens?  Why, send it in an email attachment, of course.  In other words, having a system administrator set the security policy for everyone often fails to reflect users' actual needs, and the result is that users work to bypass the security.

SELinux is similar.  In SELinux's targeted mode, the idea is that omniscient and benevolent SELinux experts will establish an access policy for each application you might ever install, specifying what files and resources that application is permitted to access.  These policies have to be based upon the SELinux experts' guesses and predictions about how you might use the application, and what you the application might consequently need to access.  However, in real life, SELinux experts are not omniscient, and sometimes they fail to anticipate how people might use their applications -- causing the SELinux policy to occasionally block legitimate program behavior.

(In principle, end users can write their own SELinux policies and modify the default system policy.  In practice, not so much.  The level of complexity makes this way beyond the means of most end users.  In practice, I would expect that 99.99% of SELinux distributions use the default policy, because modifying it in any substantive way is too difficult.)

In contrast, object-capability systems don't rely upon an expert and well-informed system administrator to set the policy for everyone.  Instead, each application is empowered to enforce its own access policy, based upon the needs of that application.  Thus, access control is not specified in advance by a single central party; instead, it is determined, on the fly, by the combined actions of application developers and users.
Least privilege?  One of the benefits of object-capability systems is that they tend to guide application developers towards designs that respect the principle of least privilege.  Because the default is that each application receives no access, except for whatever it capabilities it is able to acquire from other sources, this tends to lead towards designs where each application receives no more privilege than they need, and where the same is recursively true of components and subcomponents of the application.

Some mandatory access control systems also try to enforce the principle of least privilege.  For instance, in SELinux's targeted mode, SELinux experts analyze each covered application to determine what actions it might legitimately perform and what security privileges it needs to be granted to perform those actions.  Then, these experts write a system security policy which specifies, e.g., the list of files and network sockets and other resources that, e.g., sendmail is permitted to access.  That policy is distributed with your Linux distribution and is the same for everyone.  In principle, this can also move us closer to the principle of least privilege, but it scales poorly: it requires a handful of experts to write rules for every application covered, so they can cover only a subset of applications (hence the "targeted" mode); it is trying to restrict legacy applications, in whatever form they come, which often means that no useful restrictions can be applied (try thinking about how to write a set of SELinux rules to limit emacs; what set of files are you gonna allow it to access?  the only sensible answer is "everything", which defeats the principle of least privilege), whereas object-capability systems can do better by guiding application developers to write their applications in different ways.
Deployment experience? We have more experience with deploying mandatory access control systems than with object-capability systems.  The conventional wisdom says that traditional mandatory access control systems are usually too restrictive and often prevent people from achieving legitimate tasks, though this doesn't apply to SELinux's targeted mode.  The conventional wisdom says that object-capability systems cannot support legacy code well and require us to start over from scratch and re-design and re-implement our entire system and all applications running on it; this is probably the biggest shortcoming of object-capability systems.

There is a lot more to be said, and there is a lot written on capability-based security, object-capability systems, and mandatory access control.  This answer only scratches the surface.  I suggest you do some background reading.  Then, if there is any aspect you'd like to learn more about, try asking a more focused question.  Tell us a little bit about your particular application domain, about your requirements/goals/concerns, and what you've read so far, and then we can give you some more detailed advice.  Or, tell us more about what specifically you'd like to know, and we can give you some reading recommendations.