Transferring credit card details to hotels without PCI

I want to store the guest's credit card data in a secure way, through a third party service as I don't want to implement a PCI DSS compliant solution myself

Sorry, you still need to be PCI-compliant. Read the following:

Q2: To whom does the PCI DSS apply?
A: The PCI DSS applies to ANY organization, regardless of size or number of transactions, that accepts, transmits or stores any cardholder data.
Source: To Whom does PCI DSS apply?

That being said, you may qualify for one of the less restrictive levels of PCI-DSS.  To find out, check this link: Which SAQ is appropriate for me?
Also, depending on the hotel, you may need a lot more than just the credit card number.  Typically they will also submit name, address, expiration, and CVV in order to validate the transaction.  If they require CVV, you have a serious problem: you cannot store CVV in any form for any purpose.
Here is a good reference to get you started on your own compliance: ComplianceGuide.org.


Amateur society - What file type to use in email?

The format of the document doesn't matter.  It's a matter of balancing risk.  How lucrative of a target is your organization or its members?  How far do you think an attacker would be willing to go to get a persona on your group?  If you are sending out a Word document once a week, and all of a sudden a PDF shows up, it's up to the users to know better not to open that.

If security is that much a concern in your organization, your best option is to include all of the text in your email body, and don't use attachments.  But then again, if you are that concerned about security, it may be worth investing some money into a website or a Sharepoint site.


When does S/MIME require the other party's certificate and when is their key enough?

S/MIME builds on CMS (the standard name for what was previously known as "PKCS#7"). An encrypted email really is a CMS enveloped-data object. The bulk of the data is symmetrically encrypted, with a key which is derived/exchanged using one of the transport mechanisms detailed in section 6.2:

KeyTransRecipientInfo is basically asymmetric encryption with the recipient's public key. That's what is used when the recipient has a RSA key fit for encryption (i.e. not a RSA key tagged in his certificate as "signature only").
KeyAgreeRecipientInfo is for key exchange algorithms which are not asymmetric encryption. You will use that if the recipient has a Diffie-Hellman key.
KEKRecipientInfo is used when there is a shared (high entropy) symmetric key between sender and recipient.
PasswordRecipientInfo is used when there is a shared password between sender and recipient (which thus calls for some extensive password hashing to make up for the inherent weakness of the password).
OtherRecipientInfo is for all other cases, which did not fit in the categories above.

The critical point is that for both KeyTransRecipientInfo and KeyAgreeRecipientInfo, the recipient's public key (be it RSA, Diffie-Hellman...) can be identified in two ways:

  RecipientIdentifier ::= CHOICE {
    issuerAndSerialNumber IssuerAndSerialNumber,
    subjectKeyIdentifier [0] SubjectKeyIdentifier }

  KeyAgreeRecipientIdentifier ::= CHOICE {
    issuerAndSerialNumber IssuerAndSerialNumber,
    rKeyId [0] IMPLICIT RecipientKeyIdentifier }

  RecipientKeyIdentifier ::= SEQUENCE {
    subjectKeyIdentifier SubjectKeyIdentifier,
    date GeneralizedTime OPTIONAL,
    other OtherKeyAttribute OPTIONAL }

  SubjectKeyIdentifier ::= OCTET STRING

When the public key comes from a certificate, then the public key can be identified using either "issuerAndSerialNumber" (a copy of the "issuerDN" and "serialNumber" fields of the certificate), or with the "subject key identifier". The latter is a bunch of bytes which can optionally be included in a certificate (as a Subject Key Identifier extension). Either information is readily extracted from the certificate. You never need the complete certificate, but you need parts of it.

S/MIME also supports public keys which are not obtained from certificates, but from "S/MIME preferences". The idea is (or maybe was ? I haven't seen that in a long time) that a user may have only a signature certificate (e.g. with a DSA key). In that case, that user could generate his own key pair for asymmetric encryption or key exchange, sign the public part, and include it in messages he sends. People who want to respond can then use that public key for key transport or key agreement. Since that key is not contained in a certificate, it cannot be identified with fields from the certificate. Instead, it will be identified with a "key identifier" similar to the "subject key identifier", i.e. a bunch of bytes.

Summary: all the crypto uses only the key, but the message format must include a designation for the key which was used, and that designation will use fields extracted from the recipient's certificate (if the recipient's public key indeed comes from a certificate).


Are there tangible recommendations for USB drives to be disabled?

Annex A.8.3 of ISO 27001 relates to the management of removable media. I can't find a link to the standard itself, but there are some online resources which refer to it:

http://iso27001guide.com/annex-a/asset-management/media-handling/iso-27001-management-removable-media-requirements/

  "ISO 27001 does not mandate that removable media cannot be used, it
  just recommends that media is used in a secure manner. By specifying
  the organisations stance and implementing controls to support this
  policy, the organisation can gain a level of control over removable
  media that may otherwise pose a very high risk"

and ...

  "organisations must be able to demonstrate that the risks posed by
  removable media to the organisation are controlled. ISO 27001
  describes this as implementing procedures in line with the
  classification scheme adopted by the organisation"

https://www.isms.online/iso-27001/annex-a-8-asset-management/

  "General use of removable media must be risk assessed and it may be
  necessary to carry out use-specific risk assessments beyond that too.
  Removable media should only be allowed if there is a justified
  business reason"


Tor Browser: Could a website or ISP detect modification to DOM done by users if Javascript is disabled?

You are assuming that distinguishing yourself from the others will only be done if Javascript is enabled. But, assuming that all but you have Javascript enabled , exactly disabling Javascript might result (depending on the site you visit) in a behavior which is clearly different from the other users.
Apart from that there are HTML features like responsive images or lazy loading where images are loaded depending on the size of the browser window or only when the image gets visible - without any Javascript involved. These can be used for fingerprinting clients and client behavior too.


Are OpenPGP-encrypted files encrypted symmetrically or with a private key?

Generally, OpenPGP uses a hybrid approach: the message itself is encrypted with a symmetric encryption algorithm like AES and a distinct session key (a large random number individually created for each encrypted message), and then the session key is encrypted using public/private key cryptography. This combines the advantages of both concepts: symmetric encryption is very fast, while public/private key cryptography enables advanced key management functionality (ie., having split public and private keys).

So while technically the file is encrypted with symmetric cryptography, this is not directly visible to the user. It is not totally wrong if you say the file is encrypted through public/private key encryption, as the session key is not accessible without the private key.

OpenPGP also allows plain symmetric encryption, where the session key is derived from a passphrase without any public/private key cryptography.


Disable all SSH security mechanisms for a private subnet

Assuming OpenSSH, you can (still, but not by default) use HostbasedAuthentication which is the same (fragile) scheme used by classic rsh/rhost before ssh was invented. Namely, if the client IPaddress maps to a hostname listed in a server system or user config file, the connection is accepted.

This relies on correct and available rDNS for your local/trusted machines, so unless you are a part of a meticulously administered enterprise network, this likely means either: running your own DNS server -- at minimum dnsmasq or similar -- which is authoritative for local and forwards non-local as needed -- which isn't needed if 'private subnet' means you don't connect out at all; or editting your local client machines into the hosts file on every server (at least) and keeping them up to date.


intrusion prevention system detected "et policy pe exe" should i worry

The "ET POLICY" part of the alert is telling you that it's a 'Policy' rule: i.e. it's not an attack per se, it's just something which might violate a corporate policy.

That particular alert is just telling you that someone has downloaded a Windows executable file or DLL over HTTP. In most cases this is just noise, unless you've prohibited downloading of executable files in your environment.


is there an upper limit on time to brute-force a password, based on acceptable login delay and hardware speed ratios?

Your logic is sound, and is the basis for algorithms like PBKDF2. These increase the cost of a brute force attack to the point where it becomes infeasible for all but the smallest of dictionary attacks.


What is the easiest way for a newbie to RSA to create & use a key pair on Windows?

The standard solution to exchange encrypted or signed email is PGP or a compatible program such as GnuPG (which is free software). You and he both need to install PGP or GnuPG. There is a Windows front-end and plug-ins for email software including Thunderbird (Enigmail) and Outlook (I don't know the details and I've heard bad things about its ergonomy).

If your friend wants you to use some custom solution, explain to him that home-grown cryptography is never secure. Lead by example by refusing to use his custom scheme.


Well I pretty much answered the question already in the comments but now I'll do it as fully qualified answer.

Yes, 1024-bit RSA moduli are still in use. The samples I could quickly find are the Equifax CA certificates in Firefox. Those will be removed soon.

What would happen if someone factored any of these moduli?
Really bad things.
If you factor any of these certificates you can impersonate a widely trusted CA. This means you can issue valid certificates that will be widely accepted. The only defenses are DANE (not widely deployed yet) and certificate pinning (not possible to be widely deployed).
More practically this would mean, that you could impersonate any given server on the web (provided you can forward DNS requests to your server), as you can issue (EV?-)certificates on any site like maybe google.com, amazon.com, paypal.com, security.stackexchange.com, ... Even further you may be able to issue code-signing (EV?-)certificates, which would enable you to digitally sign malware, so that it can be installed as kernel-mode driver in Windows!

If you don't attack those CA's certificates but rather "normal" server's certificates you can easily decrypt any traffic that uses the RSA as key-exchange algorithm and you can start active man-in-the-middle attacks against those servers and easily read any traffic even if (EC-)diffie-hellman key exchange is used!


What happens when attacker scan a IP that is used by multiple devices?

Assuming ISP gives only 1 external IP and you have few devices that use this IP

That doesn't happen. There's a network address translation in between. Every device has its own IP address.
That NAT device won't just "randomly" forward things to the devices it hides. So, only the NAT device (which you call "router", but it's really not a router, in the networking sense; there's no accessible addresses behind it, from the ISP's point of view) sees the port scan.


Should it be possible in a good software, using a “Change Password” link for a single user, to try to guess passwords for every user of a Application?

One good design is to make the Change Password page accessible to logged in users in such a way that only he can change his own password. (users' identity should be bound to something out of their control(e.g sessionid) and shouldn't be sent as a parameter which is guessable and can be tampered by the user to access change password page for others)

Your application should protect against brute force attacks using solutions like captchas and/or lockout mechanisms. If there's such logic behind both of these pages then you're most likely ok, unless this kind of design is used in other parts of the application where one user can impersonate another user and make changes on behalf of others.


When you use an SSH tunnel, as far as the target server is concerned, its client is the SSH server, not the actual client connecting to the SSH tunnel.

For example, if you have an SSH client running on 10.1.1.1, connecting to an SSH server on 10.2.2.2 and establishing a tunnel to 10.3.3.3, when a client (possibly from 10.4.4.4 or anywhere else) connects to the tunnel on the 10.1.1.1 end, it gets access to 10.3.3.3 as if it was coming from 10.2.2.2., not 10.1.1.1 or 10.4.4.4.

This allows such connections to bypass firewall rules regarding the target server that would have allowed connections from the machine running the SSH server, but not further.

This is typically a problem if the SSH server is a gateway between two networks, with public IP address and one private IP address, for example. A firewall rule that would only allow access to certain services within the internal LAN wouldn't catch connections from that SSH server (unless a special case was made for that machine).

The remote connections may come from much further. On the SSH client side, some SSH clients can bind their listening socket to a specific IP address (e.g. localhost), at least to prevent connections from remote machines from that end. However, you rely on the client using these settings properly.

If your users are allowed to make this sort of connections, or if the firewall (and related) rules you use on your network handle the SSH server's IP address specifically to take this into account this, it can be fine. This being said, you may still want to check where the tunnels are established too, you could also get into trouble with other third party servers too otherwise.

If you don't need any of this, disabling this feature would be better.


Why am I getting the message that Security Stack Exchange is only partially encrypted?

When you visit https://security.stackexchange.com/, in some instances you'll be served content (ads specifically, it appears) that is over http rather than https. Most modern browsers will warn when this happens as you are seeing.

The risks are that the content that is served over non-TLS connections can be viewed and manipulated before reaching your browser in an otherwise encrypted channel. Further, any cookies that are not marked as secure while content within the same URL is served over both http and https will be exposed.

Example:

https://www.example.com/ serves mixed content from http://cdn.example.com/. Any cookies scoped to .example.com that do not have the secure flag set will be exposed while your browser fetches resources from http://cdn.example.com/.

Not only ads, but also within SE itself: <script src="http://area51.stackexchange.com/ads/proposal/js?id=a51-ad-container" type="text/javascript"></script>.


Does the principle of the CRIME & BEAST attack affect VPNs?

No. It's not at all applicable.

To be clear, both these attacks involve a malicious attacker creating a vast number of connections through the protocol and examining the ciphertext in order to determine something about the plaintext. The only way this is possible is by having a malicious actor on your computer, in your browser conducting the attack. They did this through java/javascript under the assumption that you could surreptitiously end up running malicious code through visiting a dangerous website, even though your machine isn't otherwise compromised.

The concept doesn't really apply outside the weird world of web browsers. Browsers have the unusual task of running known-malicious code safely in a restricted environment. If you're running malicious code straight on your computer which can connect over your VPN, then you're already owned.

And in VPNs in particular, the session management is different. Whereas with HTTPS it's common to create dozens of connections between a client and server, with a VPN, you create just one encrypted tunnel with a single session through which all your individual network connections will be encrypted.

So no, it's an entirely different world.


How to prove that a file was not created in advance

If all parties can trust a common randomness beacon (like the NIST Randomness Beacon), this can be achieved by including a recent block from the beacon into the file along with its timestamp.  The recipients then, in addition to verifying the signature, must also verify that the beacon data is authentic and as recent as they require.

Other public random values might also do the trick, for example, the winning numbers of a well-publicized lottery.  But care needs to be exercised however that the items chosen have sufficient entropy.  For example, if you just pick the closing value of the Dow Jones Industrial Average, that's been a 6- or 7-digit value for decades, so an attacker could just force you to precompute signatures for all likely future values of the index.  The closing values of a list of stocks that all participants agree on beforehand might do the trick, though I'd want to do some calculations first to convince myself that the list has sufficient entropy.


Safe to drop email verification when using Facebook login

The "verification email" serves three purposes (at least):

To deter evil people who automatically create thousands of users, for nefarious purposes (e.g. spamming). With the verification of emails, then such people must at least provide working email addresses, which makes them more traceable than when they do not. Also, the least competent of such wannabe attackers may find it difficult to automatically create thousands of working email addresses.
To record on your side an email address which is, more or less, working, in case you need to contact the users again.
To protect password resets. When a user registers with a given email address, then control of that address will serve as the backup authentication for that user. "Control" here means "ability to read emails sent to that address".

If you use Facebook authentication, then you surrender all of this to Facebook, so it makes sense to simply forget all about it. The lack of independent purpose for user's email address confirmation highlights the fact that you really are surrendering your server's access control to Facebook.

(Of course, confirming the user's email address is still required or at least recommended if you intend to spam him send him some sort of newsletter.)


What is the best way to defend against an already comprised computer with a keylogger that is active?

... presumably creating a file with the password on another machine and transfering via network or hot pluggable storage device. As Aria says, this doesn't protect you against something which can read the clipboard.

An on screen keyboard works around the problem in a different way - but if the logger is intercepting the key events in the gui, then no benefit.

Another option would be to proxy the connection (assuming the password is for a remote service) and inject the real password on the proxy - but this would require access to the server encryption key if the connection uses pinned keys.

One time passwords would seem to meet your requirement.

Whatever....passwords have no intrinsic value. They are critically important as a means for protecting assets with value. I.e. if you know the machine is compromised, then how can you be certain that the asset is adequately secured after authentication?


Security of master password in a derived password manager

(1) Does this design make it any easier for the attacker to find the master password than by a brute force attack?

No. Not that I see.

(2) Is a brute force attack on this design easier than a brute force attack on an encrypted password store?

Yes. There is more ways for an attacker to obtain the data that they need for a brute force attack. At least that is the case if we take your notion that there are no secrets in your database.
Suppose I set up a server for, say, MyCuteKittyPictures.net, and I store passwords on that server in plaintext. There are plenty of plaintext offenders out there anyway. An evil site operator or anyone who compromises a plaintext offender, is able to learn your password for that site.
This gives them everything that they need to launch a brute force attack except the salt, but you have said that the database file is not a secret, and therefore I should assume that the attacker has access to the salt.
In my example, I talked about a single plaintext offender (and a malicious one), but data from any plaintext offender puts the attacker in a position to launch a brute force attack. And so there is more opportunity to an attacker obtain enough data to launch such attacks

(3) Is this in any other way easier to attack than encrypted password managers that derive the encryption key from a master password?

This is going to depend on some fine details. But on the whole encrypted password managers will generate passwords that are truly independent of each other.
Also what you are calling encrypted password managers will have the ability to encrypt the site, and username, and other data which a user may wish to keep private. I may not want to world to know whether I have a login for ToenailChewersAnon.org or that I am user fluffybuns on some other site.
So you really aren't gaining anything by pursuing yet another attempt at a derived password manager. And you are losing other desirable processes.


Short answer: You need to find a different approach to meeting FCS_CKM.2 requirement.

Long answer: Until next revision of SP800-56B finalized, RFC-conforming TLS is not directly compatible with SP 800-56B. The issue is establishing a common shared secret. In SP 800-56B it is defined differently from how RFC-implementing TLS operates. NIST realized this, conceded that nobody uses their method with TLS, and allowed in SP 800-56B rev.1 "application-specific" use of SP 800-135 KDF that is compatible with how TLS operates.


There are several dependencies between the standards in the ISO2700X series also called the "ISMS family of standards" that are not clear from the beginning - so your question is absolutely justified.

Fortunately there is a Figure for that:

Source: ISO/IEC 27000:2016

What every single standard does can be somewhat inferred from their names. So here's a short list:

Vocabulary standard:

ISO/IEC 27000, Information security management systems — Overview and vocabulary

Requirement standards:

ISO/IEC 27001, Information security management systems — Requirements
ISO/IEC 27006, Requirements for bodies providing audit and certification of information security management systems
ISO/IEC 27009, Sector-specific application of ISO/IEC 27001 — Requirements

Guideline standards:

ISO/IEC 27002, Code of practice for information security controls
ISO/IEC 27003, Information security management system implementation guidance
ISO/IEC 27004, Information security management — Measurement
ISO/IEC 27005, Information security risk management
ISO/IEC 27007, Guidelines for information security management systems auditing
ISO/IEC TR 27008, Guidelines for auditors on information security controls
ISO/IEC 27013, Guidance on the integrated implementation of ISO/IEC 27001 and ISO/IEC 20000‑1
ISO/IEC 27014, Governance of information security
ISO/IEC TR 27016, Information security management — Organizational economics

Sector-specific guideline standards:

ISO/IEC 27010, Information security management for inter-sector and inter-organizational communications
ISO/IEC 27011, Information security management guidelines for telecommunications organizations based on ISO/IEC 27002
ISO/IEC TR 27015, Information security management guidelines for financial services
ISO/IEC 27017, Code of practice for information security controls based on ISO/IEC 27002 for cloud services
ISO/IEC 27018, Code of practice for protection of personally identifiable information (PII) in public clouds acting as PII processors
ISO/IEC 27019, Information security management guidelines based on ISO/IEC 27002 for process control systems specific to the energy utility industry

You don't won't need every single one of these. It is best to start with the ISO27000 to get a good overlook. All the dependencies within the ISMS family of standards are explained here. Luckily this standard is available for free on the ISO website, although a little hidden1. After you have understood what you want you should know what standards to buy.

But, the important part here is this: the cost for buying the standards is probably insignificant (100 CHF+ per standard) in comparison to all the cost you will have when implementing your ISMS and getting ready to be audited. This is a very long and somewhat expensive process. Worrying that the 200 CHF you will maybe pay the ISO is too expensive, is the wrong mindset for this.

1 You can visit this site: https://standards.iso.org/ittf/PubliclyAvailableStandards/index.html or look for "Publicly Available Standards".


How secure is LAN wireless 802.11 if password is used with access point?

"How Secure?" is a difficult question to answer.  It depends on your particular circumstance and risk tolerance.

If you are using WPA2 for encryption with a complex key, than I think it's reasonable to say that your connection is at least as secure as a wired Ethernet connection.


Can a device accidentally transmit a Teardrop attack?

This is inconclusive.

Because port 3702 is assigned to WS-Discovery :

  Web Services Dynamic Discovery (WS-Discovery) is a technical
  specification that defines a multicast discovery protocol to locate
  services on a local network. It operates over TCP and UDP port 3702
  and uses IP multicast address 239.255.255.250. As the name suggests,
  the actual communication between nodes is done using web services
  standards, notably SOAP-over-UDP.

So it can be anything in the Android(tablet, phone,etc) that make use of WD-Discovery. If you think none of the Android application should talk to any local web services, then you should carry out further investigation, e.g. turn off all application and turn on one by anytime to observe network behavior.


Possible issues when one or more cookie not HttpOnly

The HttpOnly flag only serves to protect sensitive cookies from scripts. Assuming the load balancing cookie is only concerned with routing through to a specific server and cannot identify a client, there's no harm in  this cookie being exposed. A XSS attack will only identify which server the browser is connecting to, and not anything specific to the client that an attacker couldn't figure out anyways.


A VPN is not a firewall by itself but only a virtual tunnel which has another public IP  on the tunnel endpoint than your systems current public IP. A VPN by its own offers no protection against attacks, it protects only the communication between the tunnel endpoints against sniffing and manipulation.

Thus, the attacker would not need to hack your VPN in order to access your system. It only has to attack the tunnel endpoints IP address instead of your systems public IP address and the VPN will forward these attacks through the tunnel to your system.

Of course a VPN might be combined with a firewall or NAT and would offer some protection this way - but this is then a property of the firewall or NAT and not of the VPN.


The JSON for an authentication request containing multiple authenticator (token) key handles looks like this. (challenge and keyHandle values were shortened)

{
  "type": "u2f_sign_request",
  "timeoutSeconds": 30,
  "requestId": 123,
  "signRequests": [
    {
      "appId": "http://localhost:8080",
      "challenge": "7Wr...I6w",
      "keyHandle": "8BB...7YQ",
      "version": "U2F_V2"
    },
    {
      "appId": "http://localhost:8080",
      "challenge": "9Qb...HOE",
      "keyHandle": "5i8...CEJ",
      "version": "U2F_V2"
    }
  ]
}

NOTE: This is for the currently published public U2F Javascript API.
https://fidoalliance.org/specs/fido-u2f-v1.0-nfc-bt-amendment-20150514/fido-u2f-javascript-api.html

dictionary Request {
    // The type of request, either "u2f_register_request"
    // or "u2f_sign_request".
    DOMString          type;

    // A list of SignRequest dictionaries, one for each
    // token already registered with this RP.
    SignRequest[]      signRequests;

    // A list of RegisterRequest dictionaries, one for each
    // protocol version that the RP is willing to register.
    RegisterRequest[]? registerRequests;

    // A timeout for the FIDO Client's processing, in seconds.
    int?               timeoutSeconds;

    // An integer identifying this request from concurrent requests.
    optional int?      requestId;
};

dictionary SignRequest {
    // Version of the protocol that the to-be-registered U2F
    // token must speak. E.g. "U2F_V2"
    DOMString version;

    // The websafe-base64-encoded challenge.
    DOMString challenge;

    // The registered keyHandle to use for signing, as
    // returned by the U2F token during registration.
    DOMString keyHandle;

    // The application id that the RP would like to assert.
    DOMString appId;
};

dictionary RegisterRequest {
    // Version of the protocol that the to-be-registered U2F
    // token must speak. E.g. "U2F_V2"
    DOMString version;

    // The websafe-base64-encoded challenge.
    DOMString challenge;

    // The application id that the RP would like to assert.
    DOMString appId;
};


Malware is any software which performs malicious activities. Malware comes in all shapes and sizes, and with all sorts of infection vectors. Exploiting a software vulnerability is one way malware can spread, but there are many other (often more common) techniques they use, for example:

Brute forcing passwords over a network to gain access to a network.
Spreading to other computers on the same network over shares, etc.
Tricking the user into executing a malicious file with a benign name.
Tricking the user into performing an action that executes code (e.g. ldd).

Never overestimate the difficulty of tricking the average person into executing malware. Often forgotten techniques such as using unicode reversal on filenames can show a user a different filename than is really present. For example, a file called history_of_rac4pm.msi seems safe enough, right? It's actually history_of_rac4pm.msi, but due to unicode reversal, the last seven characters are mirrored, giving the impression that an executable installer is a video! Check the HTML!

It doesn't even have to involve making them run an executable file. There are many actions that execute attacker-controlled code that people do not think about. Consider ldd utility in Linux. All it does is list the libraries required by a given executable file. Seems safe enough, as long as you don't execute the file? The reality is that ldd is actually a wrapper that executes the file with an environmental variable set which causes the executable, if using a correctly-behaving libc, to output the libraries it requires to stdout and then exit. It is trivial to create an executable which will not do that, so running such a simple "safe" utility on it will actually end up executing malicious code.


Why is "MIME type mismatch on image file" a security vulnerability?

The problem is with the browser (or in the case of the linked CVE with Outlook).

The attack is as follows:

I create a file and send this file to the program with the MIME type image/png.

The browser ignores the MIME type and sniffs the content of the file (even I explicitly say that the file is of type image/png).

The browser determines (from sniffing) that the content type is text/javascript and handles it accordingly (as Javascript).

Therefore in my eyes this is a flaw in the browser because I clearly determined that the file is of another type.


Mifare Desfire symmetric authentication with master key on android

The key does not need to reside on the app.

When you ask for authentication, you will get a random number, encrypted with the key, back.
This random number, you can send back to the server with the app, and let the server do the authentication with key. The server will then send you a new encrypted packet with a encrypted value, that you just forward to the chip. Then you will get a response from the chip, that you send back to the server.

After that, the cell you are using could contain some product info, "signed" with a MAC. This product info and MAC is also sent to server as a final phase.
Only after all the steps completed successfully, product is genuine.

If you use any libraries to do NFC communication, you must run these in manual mode to be able to authenticate this way.

It is possible to create a rogue app that will read the resulting data and copy the product info inclusive the MAC, and then insert this into a fake DESFire EV1 chip that will accept any authentication. This is why the server must validate the random value that is returned, that this successfully decrypts to the value the server initially selected, but shifted to the left. (read the implementation details on how you do a authentication).

By using keys that cannot write the chip, you also prevent someone from updating a genuine chip to contain information about a product more expensive than the product the chip resides on.

Be also careful that someone may move the chip from a genuine product to a fake product, and then keep the genuine product itself, and sell the fake product. Use tamper-resistant chips for this, that will stop working once they are removed from the product. Or tie the product to a service requiring authentication with the app to work, thus the genuine product that the fraudster have will be useless without the chip.


How should I protect an algorithm that I want to sell?

Anything you hand to someone can be cracked, known, and ultimately under their control. You can try to make it difficult to understand or use, but that will ultimately fail.
So, you need to change your business model to retain control over the process, or not care if someone uses it without your permission.


Can I get a windows virus on macbook via usb transfer?

Depending on the circumstances, nature & capabilities of the virus/malware.

The very fact that a USB drive is writable and does contain memory space makes it susceptible to being infected.

However, infecting a new host with a different OS (in your case, MACOS) is also another set of risks. Certain viruses/malware are created to cater to certain machines and OS hence if they are configured in a way so that they could run on cross-platforms then yes they can infect your new host.

It is also good practice to turn off auto-run/auto-play when USB devices are connected to a machine. This prevents programs from running automatically upon insertion.

Now let's move on to the file(PDF). In the above paragraphs, I have discuss the idea of plugging in the USB drive to extract the said file and the risks of that, but how about the file statuses? Is it infected?

The answer is that any file can be infected & armed by other viruses/malware, to determine whether a file is malicious is not solely based on its file extension.

All that being said above, it boils down to the very nature of the virus, there will be risks & vulnerability involved, for sure. Just 'virus' itself is very vague.


Site listed as hacked by a hacking group

It could very easily be a false claim - and it sounds like you have done the right things regarding checking logs, database etc - and you can perform in-depth forensic analysis (either yourself or contract one of the many companies that do this) but if you are in any doubt you should plan for the worst - a rootkit.

If you have a well concealed rootkit, the only option is to completely wipe the machine and start again from known good sources.

Your point about a hacker's list depends on what they are saying. If it is purely a 'we defaced/pwned these sites' list, then I wouldn't think anything of it once you have secured it.


Why is Google trying to communicate with svchost.exe

Try the following to identify what is communicating with Google:

Since you have the local port and destination run netstat -ao or netstat -nao to get the PID.
Now that you have the PID run Sysinternals Process Explorer with elevated/administrator permission.
Find the svchost with the corresponding PID.
Hover your mouse cursor over the process.  The tooltip will inform you of the different services running under that svchost.

Now that you've identified the right svchost, its a matter of figuring out which service within the process would be contacting Google.  Often they're unique enough where this can be easily determined at a glance.


In general no, without certs installed on the user's computer, SSL traffic won't be visible.

They could play tricks with non-SSL connections, but if the app successfully creates the SSL tunnel, it should be safe.


Full credit card photo (front and back) accidentally sent to a customer service, what to do now?

Immediately call your bank's Lost and Stolen credit card number, found on the back of your credit card.  Tell them what happened, and they will take the appropriate action.


Is it completely safe to publish an ssh public key?

Public Keys are designed for sharing, read access to and or publishing a public key is fine

Private Keys are secret, they should only be accessible to the owner of said private key.

To drive this point home, think back to every HTTPS website you have ever visited.  In each case, as part of HTTPS the site gives you their public key.  So not only is it safe to publish it, it is intended to be this way.  For example, if you click on the green lock icon on your address bar, you can find the public key for this website (if you are viewing it on HTTPS)

*.stackexchange.com

Modulus (2048 bits):
af 46 03 ce c7 13 e6 2e 93 d8 56 91 b1 31 8d 0a
22 c1 f0 eb 4f 5e ef 0d f6 20 32 b9 a4 4e 87 f9
d2 d2 44 51 b0 df 30 50 c9 35 4e 68 19 84 fb 98
33 aa 05 4b 7e fb 57 c5 b6 2e a8 4b 04 ca cf 5e
2e e5 9e 1b ca b7 60 c5 58 2c b0 df c4 6b 0d b1
2c 33 97 73 54 61 2b 9a 1b b1 dc 5d 10 a9 c4 c8
f7 6c e3 55 6e b5 0e 61 3b 35 24 0b 89 1e 32 a2
75 69 4e 97 40 68 ee 23 48 f2 71 9f c7 7e e2 9d
6c 22 55 36 24 64 a4 f0 b6 52 58 5a 9a 44 e7 3b
2a d5 ed 95 63 f8 1d a8 4d 45 9b 5d c2 f2 f9 74
81 06 18 d5 b1 fb b0 7e 5d 50 1f 63 5c a0 73 f5
22 b2 57 64 03 e6 b7 0f 6f b7 58 0b 57 80 56 51
65 9f f5 09 61 63 29 62 4d 30 02 3a 64 10 2d 95
b8 12 36 04 58 c5 d7 1d 95 e2 21 3c b0 b3 93 35
b2 b1 f9 6d 7e 20 66 b2 68 33 e9 50 a8 15 1e 0a
80 9a 3c 19 dd cc 79 35 a8 8c 1b 61 33 5d 12 2f

Exponent (24 bits):
65537

Further examples of this can be found on github.com where they request that you attach a public key to your account for use with git clone git@github.com:<user>/<repo>

You can actually check the public keys of any user on github with the following URL

https://api.github.com/users/<user>/keys

mine is listed as:

[
  {
    "id": 18667533,
    "key": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDraswAp7EbMwyYTzOwnSrsmr3nNMDaDf4e2YVaehLc9w6KN2ommomXZO8/V9N3yINNveGqrcVc9m2NTm04iILJUKd9o25ns8QIG6XSCt9SVx/Xw1J/SXfIWUKuEe0SgmIwVwkk8jetfG/Z7giSiU3dxxC4V9lHQCFgKOKBWGpNbINmqtmBWncX3HJKeXrpSddoePbZZ84IEFr4CWUlqoXyphpxqzpfA9sRpVTtyBPcUSj68j4+gKgEQN65G6LXys3q8BiwWxucci6s34vp4L8jKn7uYh26vLuT1oIbODJphCmpvMH+ABPkNQcFBk4rRLpCEAsoAhmvTk/NjnfZM+nd"
  },
  {
    "id": 21175800,
    "key": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC5tPV481acCZ5wm2E15gXkVRaKCE3lic/O8licyzW+eDE9rPpG4rHRRH9K2ENmstUh5nLEenb0nNhEGnsf3pIJRZ07JXwv16+lsJBSS8+YiWeMBlwo+JNaxwSyUlYUgl1ruogr0nR0KBqsYSWXuG0s2jm2IOV+0B/0fzDR/tiLFLj50+iJ9qCDSk/8fAsXz2xG39KcUcxmCbDXb/qSdESWaZc+pafNRiCcVNfMkKeDViWlzI4VkiTcfVCraHUuYx4jgOBB526dRWSDG9bLchwlJiopgT+k4X/TNe2l01DPwYetwLvY6V8rcPrjjJL8ifRTMSof1zRIoBgJZhRzWc1D"
  }
]

The exact opposite is true of Private Keys which should be secured at all times and never given to a third party or exchanged via email without encrypting them.

If someone has accessed your private key, they have the ability to access any device or encrypted file that was protected with your public key.  It also means that they can sign things on your behalf. It is VERY bad if someone has gained access to your private key.

In many cases SSH Clients will not function if it is detected that the permissions of the Private key file are such that users other than you have read access.


How to use password certificate in code securely

You should ask your developers if they are completely mad. There are a number of serious issues, that show the lack of competence of your developers.

Hard code variable data. So, if anything changes, for example you change the password, the developers need to be called in to change the software (including the tests, install etc.) In the past that was great for job security.
Encode sensitive security data, in this case the password. Like you already guessed, if someone sees the source code, your security is lost. The fact that they have done this means that they have no clue or regard for security.
Your certificate has a limited life-span. That means that your new certificate must have the same password or else your developers need to recompile, test and distribute the software.

So what should you do?

Change the password. Consider it compromised, because all the developers know it by now.
Examine whether the password on the certificate adds anything to your security; determine what risks are mitigated by the password. If you properly manage the private keys, it might not be necessary to use a password. On the other hand, if you need a password, that should be entered when the program starts.
Examine how, for example, ssh stores its secrets. On UNIX/Linux systems, that would be in a directory with 700 / rwx------ and all the files will have 600 / rw-------, so only 1 specific user has access to them.


How far beyond using Shred should I go when deleting files?

If you fear for the confidentiality of data, you should have used encryption, preferably full-disk encryption (TrueCrypt has good repute). With encryption, you do not have to worry about the disk itself, only the key; destroying the key is as good as destroying the data. This makes the problem more manageable.

Assuming that you did not use encryption, and that you have a disk where a lot of very sensitive data has been written, and you want to destroy it beyond any recovery. Then you should destroy the disk itself. Don't shred the files, shred the hardware. You could employ other methods (melt the disk in a furnace, dissolve it in acid, wipe it with an EMP from a nuclear blast...) but the mechanical shredded is probably the safest to use in a home or small business ("safest" but not "safe": beware of trapping your hands in it !).

If the price of a new new disk makes you cringe and grit your teeth, then maybe the data is not really worth a lot ? Otherwise, there is no possible hesitation.


How long would it take to brute force the AES encryption?

There are a few things here.  First and foremost, you don't need to encrypt a hash.  The point of a hash is to protect the original password.  Symmetric encryption on top of that doesn't add much since it is fairly likely that the key will be compromised if your servers are compromised anyway (which should be the only way that someone walks off with your user DB).

Second, if you are using a random IV but I don't see it being stored.  I'm not that familiar with mcrypt specifically, so forgive me if it takes care of storing the IV in some format with the encrypted output, but if you don't store the IV in some way, decryption will be impossible.

Third, use a secure, slow cryptographic hash like bcrypt rather than SHA256 and you will get much further security from the hash itself.  Speed in hashing is bad and encryption is unnecessary and ineffective.  Use a slow enough hash that generating rainbow tables is cost prohibitive but verification is not and you should be fine.


what is the best algorithm for hashing stored users info on client-side on a web app

Firstly, My recommendation is to never stored some sensitive information at a client side.(i.e Password).
Best Solution for your situation is to use the Auth0. They provide the Authentication-as-service platform.
Basically they use the JWT token based mechanism. JWT token provide encryption mechanism to stored and transmit your data. In which you can set your expiration time as well.
Some of the links are given below.
I hope this information may help you.

https://davidwalsh.name/react-authentication

https://jwt.io/introduction/


Is it safe to buy a router if its serial number and other details are exposed on the web?

Yes this is safe.

Default password and PIN are irrelevant if you change them (or replace the firmware.)
Serial number is irrelevant anyway.
Part number is irrelevant anyway.

Which leaves the MAC address. With some routers this is used to compute a default password, but once you change this I don't believe there is any risk.

The biggest risk of any router is the potential presence of backdoors that the manufacturer firmware may contain, but given that you are replacing it with DD-WRT that does not matter.


Would it be secure to procedurally generate passwords based on a master key and an account label?

I suppose if someone knew what my accounts were, had multiple generated passwords and knew the labels for each and knew the method of generation they could reverse engineer my master key?

If the password generation function is CRC32(master_passphrase||label), it could probably be reverse-engineered.

Now if you use a cryptographically secure hash function, like SHA256, it will be computationally unfeasible to determine the master password.

Security can be further improved by using PBKDF, which uses a cryptographically secure hash function in multiple rounds to slow brute-force attacks (and, possibly, also worsen the complexity of future attacks based on as-yet undiscovered cryptographic weaknesses).


Is XRY Forensic Tool able to extract data from iPhones?

As far as I know you're correct.  For confirmation I had a look at their release notes here and on the second to last page at the bottom left it lists the iOS physical support and has a foot note which states (iPhone 3GS, 4 CDMA, 4 GSM, iPod touch 3G and 4 and iPad 1 are supported.)

From that I'd guess that iPhone 4S/iPad 2/iPad 3 are out of reach due to a lack of a current public DFU mode exploit.


How do I respond to a published security vulnerability in my application?

For the future, there is one critical thing you should be doing:

Provide an easy way for people to report security bugs to you.

I took a look at the web page for your application, and I noticed it doesn't seem to list any way for a security researcher to contact you with a report of a security vulnerability.  There is no email address to report security vulnerabilities, or at least I couldn't find one.  I couldn't find a bug tracker that lets people submit a confidential security vulnerability report (or even any bug tracker at all that lets a member of the public submit a bug report, let alone a confidential report of a security bug).

See, e.g., CERT's Recommendations to vendors and Hey corporations: Provide a easy way to disclose vulnerabilities to you!.

Of course, this is not a silver bullet.  Even if you do provide a clear way to report a security vulnerability, some folks still might not contact you -- but some responsible researchers will.  In any case, I can tell you one thing: If you don't provide any obvious way to contact you with a security bug report, that significantly diminishes the likelihood that security researchers will do so in the future!

There are also some additional steps you could take, if you wanted, but these are optional and beyond what I would classify as important or essential for an open-source project:

Do a security assessment of your own code.

You could use security static analysis tools and black-box penetration testing tools to assess the security of your own code.  This way, you have a better chance of detecting any security problems yourself, before others discover them.

See, e.g., What are some good, free tools to run automated security audits for PHP code? and How to perform a security audit for a PHP application?.  Also, take a look at RIPS, a tool that scans your PHP code to try to find potential security vulnerabilities.
Follow places where vulnerabilies are disclosed.

You could try to keep track of various places where vulnerabilities are reported publicly.  For instance, you might follow the full-disclosure mailing list.


Allowing any third party script to run on a page capturing user data means that third party could potentially capture any of the same data themselves. Whilst Google is probably safer than "random-site-x.com" on the web, you're still trusting that:

They won't capture your users' personal information and bank details and let them leak
They won't modify any of the data users are submitting in any way
They aren't letting any sources modify their script before serving it to you
They haven't let their server be compromised by some other third party
Your user doesn't have any malware that may redirect Google requests elsewhere

Google are likely a bigger target than whatever website you're managing, so you're leaving a lot of trust in their hands to keep their script/servers at least as safe as your own website. You're also leaving a lot of trust in their hands to play nice with your customers' personal data.

Depending on your jurisdiction you may also be responsible for ensuring that you don't share certain customer data with third parties (e.g. certain interpretations of EU data protection laws), so you should consider if that applies to possibly sharing customer purchase data as well.


How is an X509 certificate signer verified?

In a X.509 certificate, the name of the issuer (in your example, A's name) is also included (as issuerDN). Also, a certificate can contain an extension which points to a place where the issuer's certificate can be downloaded (the "Authority Information Access", section 4.2.2.1 of RFC 5280); note that since all certificates are signed entities which are accepted and use only after having verified these signatures, they can be downloaded and transported with little care. Finally, it is customary, in protocols where a party can show a certificate, to actually show a list of certificates containing needed intermediate CA certificates. This is what happens, for instance, in an SSL Certificate message.

All this gives a lot of ways for a computer to do certification path building, i.e. reconstructing chains of certificate on which validation (including verifying cryptographic signatures) seems relevant.


There are websites out there, that will not be updated as soon as the first browser supports your proposal. Those sites will not check the XHR-Origin header and are therefore vulnerable.

Vulnerability example

Let assume you are logged in to your bank. Without logging out, you visit another website. This website sends an XHR-request to your bank to request a JSON response, which is used in the account history view.

Yes, this request will have a XHR-Origin header, but if the bank software is not adjusted, it will reveal sensitive data.

So it is the responsibility of the browser not to break existing SOP restrictions.

Is CORS fully SOP compatible?

The CORS specification makes a number of exceptions for which the preflight check is not required. Those are based on situations, in which the SOP was never enforced in the psat (e. g. form submissions).

The problem in the current draft is, that it is solely based on the Content-Type header, but web applications tend to ignore it.

There was a nice talk by Shreeraj Shah at Blackhat Europe 2012 on HTML5 Top 10 Threats: Stealth Attacks and Silent Exploits


Methods for analysing android app on runtime

You can try Frida it is an amazing dynamic instrumentation toolkit for developers, reverse-engineers, and security researchers. You can analyze the behavior of the application and run-time and you can easily perform run-time analysis using it.


There is not a top 1000, because that wouldn't actually be relevant to most people. The OWASP top 10 are chosen because they are applicable across the vast majority of web applications, and are likely to be exploited if you do not secure them.

Beyond that, if you are starting from a position of already having applications and infrastructure:

Understand your assets - have a list of all your applications, platforms and versions

This can be very challenging in a large organisation, but without it, how will you know what you are vulnerable to?

Cross reference this list with the CVE database to understand the types and number of vulnerabilities which apply to your assets

The CVE database goes to the level of specific versions of applications and platforms so you can get a very tailored view of vulnerabilities you should be aware of. It also provides a rating (from 1 to 10) and a description of how the vulenrability can be exploited (eg local, remote etc)

Identify your threat actors

This could be environmental activists, terrorists, competitors, foreign governments, bored students, organised crime gangs etc.

Assess impact and likelihood based on the previous steps and prioritise remediation

You can never protect against all possible attacks, so this step is essential to help you decide where your limited budget and time will have the best return. If you can't articulate the value of a remediation project to the board you may find it difficult to get buy-in and budget.

Implement remediation activities
Rinse and Repeat - security never ends

A better position is to build a security governance framework which helps define and assure security in the development lifecycle, so this will help you build an architecture and testing plan to help reduce the likelihood of vulnerabilities getting into code in the first place - but this is a much longer discussion, and probably will see you utilising consultants :-)

tl;dr - OWASP Top 10 will give you the best initial view on what you need to do to protect yourself. After that check the CVE database for specific vulnerabilities for your code. Improving your procedures/framework/SDLC will protect you best in the long run. Proactive, rather than reactive.


SSL Decryption why is the root CA certificate required on clients?

The reason is that most cert stores do only treat CA certificates signed by itself as root certificates. SubCA certificates will in most cases be added to a store called "intermediate certificate issuers". This store does not add any trust to the certificate, its only as a convience to the computer in case the server only sends its own cert, not the intermediate certificate that links to the root.

(some misconfigured server might send only cert (A) of (A)-(B)-(C). If the (C) is in root store, the computer wont be able to complete the chain and would complain on (A) being untrusted. Thus (B) is added to the intermediate store, which is not trusted, but adds the link between (A) and (C), making (A) trusted. The reason its unsafe to trust (B) automatically, is that (C) might get revoked and any linked certificate must revoke too)

Any certificates in the "intermediate certificate issuers" must chain up to a certificate inside the trusted root store to be trusted.

But in most certificate stores, it should be manually possible to inject a certificate in the root store even if it not signed by itself. Sometimes, you must check a checkbox that you want to install the cert manually, sometimes you need to manually wander in the stores and add the certificate using a button


Staying logged in as a user for remote access (such as Team Viewer) Pros & Cons

There still are two risks even with good password strength and good access control in the office.

Even if Team Viewer pays high attention to security, there is still a possibility of the program being compromised, as in remotely exploitable by some kind of vulnerability. PC's staying on in the week-end would allow an attacker to freely use the exploit while the guy supposed to monitor security is doing a BBQ with his friends.
The access control might be as good as you want, but if the threat comes from inside it is useless. Let's say the manager is on a business trip and lets his pc on to access with TeamViewer from his laptop, John who is a bad guy, wants access to said manager's info for whatever reason, he can stay in office until 7:30pm and wait until everyone has gone home and have fun with the manager's data.

Except for this, AFAIK it should pose no problem. It is a matter of how much you trust Team Viewer and how much the company trusts its employees.


Why limit internet access while connected to a remote desktop?

One of the primary concerns to limiting Internet access revolves around downloadable threats.

Malware that may be part of a botnet.
Viruses
Rootkits
etc..

These threats can obviously compromise security and is a common methodology used by attackers to gain entry to an environment.

If you get an agent based executable installed to your workstation that reports back to a central command and control mechanism it can be told to download keystroke loggers, remote access tools and other nefarious software that once installed can be used to further compromise the local infrastructure your machine is located in.  Your machine would be seen a beachead, if you will, for an attacker to get a toehold in your environment to further exploit other infrastructure that is available to you, the private user of the infrastructure.


Why should I pay for an email S/MIME certificate?

If you have confidence in the security and policies of the company issuing the certificate (that they would not issue one to someone else for addresses in your domain) there should be no difference. Most of these shops offer the free e-mail certificates as a way to advertise to you for Web server certificates and the like. Many of the paid offerings provide insurance against anyone else getting your certificate through the company's error or by hacking their servers, and then impersonating you.


What type of attacks can be used vs MongoDB?

Insecure Direct Object Reference

Client-Side Enforcement of Server Side Security

Server-Side JavaScript Injection

Also MongoDB should not be assessable to the public.  It can be password protected,  and passwords can be brute-forced.  Client-Side js can communicate with MongoDB directly,  and MongoDB can authenticate individual users. However their authentication system is overly simplistic,  and in practice I have only seen this design fail.


Are virtual "canary" systems used to detect malicious programs?

The colloquial term for that is honeypot. A honeypot system must be attractive for the attacker, but otherwise constrained so that it does not help the attacker in his nefarious schemes. This is a rather delicate balance. For instance, a honeypot to trap spammers must look as if it could serve as relay for tons of spam, but preferably not allow much spam (or any) to actually be sent.

Virtual machines are a method to make several systems share the same hardware, and yet be (nominally) isolated from each other. Escaping from the VM is normally impossible, unless the VM engine has a security hole, and existing VM engines do have security holes, so hosting a honeypot in a VM is somewhat risky. It is understandable that, for a honeypot, you want something cheap (it will not contribute much to your business, after all), and a VM is usually cheaper than a physical server. But it is really safer to use a physical machine as honeypot, with good network separation (explicit firewalls, no VLAN...). On the other hand, a VM can be snapshot, which is very convenient for post mortem analysis.

The main point of a honeypot is to serve as an observation deck to learn what kind of attacks are in vogue. Companies who write botnet detection systems run honeypots to have botnets to observe under controlled conditions.


Does preventing consecutive characters in a password actually increase security?

Preventing consecutive characters reduces security.  It's an attempt to prevent simple-to-guess passwords such as 00000000, and to prevent people from padding weak passwords up to meet minimum lengths, eg. helloooo.  However, it also prevents the use of a wide range of strong passwords.

Sticking to just eight-character lowercase passwords for simplicity of analysis, there are 208,827,064,576 possible passwords.  Approximately 56,000,000,000 of those passwords contain consecutive identical characters, so in an attempt to prevent the use of weak passwords, you've reduced the complexity of a brute-force attack by about a quarter.


Are photographs of fingerprints a security risk?

An excellent slideshow on this topic (in my opinion) is the one from Marc Rogers.
Basically, he says the following:

Most fingerprint systems can be hacked
Fingerprint security provides convenient security, not military grade security

I also like the analogy in his explanation:
Door locks have been defeated with increasing elaborate picking techniques
as long as they have been around.... but we still use them.
 - Security DOESNT have to be perfect.
 - It just has to be ENOUGH.

Fingerprint manufacturers are constantly looking for mechanisms which can detect 'liveness'. See for example this research.

In an ideal situation, fingerprints should not be used as the only factor to authenticate someone, but they can be used to provide access in case the system is 'almost' certain it is you that wants to enter (e.g. because it recognizes your clothes, or because your voice sounds familiar). If the system is not certain at all, it must still fallback to a better security measure (such as a complex password).


.net System.Security.Principal.WindowsPrincipal user namespace ldap injection

I can infer from your question that you are using a SPNEGO LDAP Web Server Delegation Authentication scenario.

This means you shouldn't be allowing anonymous authentication in IIS, since you're delegating into IIS to authenticate the user you have no choice on your app but to accept whatever answer IIS gives you. If you have anonymous authentication it might be possible for a user to claim to be someone that he is not.
Also, usually System.Security.Principal.WindowsPrincipal is used to know what user is running the application and System.Web.HttpContext.User is the right object to identify the user logged in through the web request.

This analysis might be way off, I would need to see application pool configuration, IIS configuration and authentication module implementation details to be sure of what is going on.


Fake email addresses most typically server as spamtrap (kind of honeypot). They idea is, since that such a email address would never be used to receive any legitimate emails, anything that comes is a spam. These spam messages are later analysed and used to update various RBLs (Real-time Blackhole List), nowadays most typically DNS based black list.

Upon receiving connection from blacklisted spammer, rather than rejecting connection right away many servers would use tar-pit technique. Which means basically keeping connection open until it times out. The idea is, that SMTP is typically transported over TCP, meaning that single computer has limited number of simultaneous connections (open sockets) it can make. Thus, should spammers use standard SMTP server with standard settings, tar-pitting would seriously hamper their throughput. However, all of above techniques are completely useless when spammers use botnets.


Security implications of android rooting

I will confine my answers to Nexus phones.

I have rooted my Nexus phone. I am sure that rooting will work on new Nexus phones. ( Samsung phones can also be rooted)

Rooting does not rely on any particular security hole. The broad idea is to be able to execute commands as a root user (as like in the linux system).
Rooting a phone in itself cannot be termed as an attack; But the catch is if someone steals a phone and then tries to root it, it can be a problem. Nexus phones will be wiped completely during the rooting process.

Regarding the security risks for running apps on rooted phones.
A very simplistic example would be, if an application caches an authenticated session cookie (or password) in an area in the phone that cannot be generally accessed by the user (on non rooted phones), then it can be accessed on rooted phones. (Loosing a rooted phone can lead to password theft or cookie theft quite easily)

A not so simplistic example would be an attacker trying to run an application on a rooted phone and using maybe IP tables on the android phone to redirect traffic to a proxy (for an application that cannot be generally proxyed).

To protect against these kind of threats, applications employ root protection mechanisms that results in applications not running on rooted phones or running in a restricted manner on rooted phones.

There are counter applications that try to hide root capability to bypass root detection defense mechanism. They work at times.

But a really skilled attacker can go upto the level of modifying the source code of the apk and using modified version of the application to suite his purpose.

Hence the best way for an application is to not rely on the client side for protecting sensitive data or on the integrity of the data received ( the source code or the assumption that the application will not work on a rooted phone)

To root the phone, i had used this as a guideline and it had worked for me.
http://www.ibtimes.co.uk/root-nexus-5-nexus-7-2012-wi-fi-android-5-1-lmy47d-lollipop-firmware-1491474

You can use the superuser application on to manage the other applications with root access. So if an application is requesting root access, you will have to explicitly allow it via the super user application.
https://play.google.com/store/apps/details?id=eu.chainfire.supersu

I am not sure if this has answered your questions completely
Do let me know if you have any queries, and i shall try to answer.


User account password encryption by web based emails service providers?

They are not encrypted, they are actually hashed: they are both cryptographic operation with the difference that hashes are irreversible.

One cannot simply "decrypt" a password hash. However, given a password, one can generate a hash for it.

If an attacker has obtained by some mean the content of the password hashes database, he can then think of a random password, compute its hash, compare this computed hash to check if it matches one the hashes stored in the database. If it does, then it means that the attacker has just guessed the right password for the corresponding user!

To make the process quicker, the attacker would use two main means:

Instead of thinking of a random password, he will use a very large list of the most frequently used passwords and dictionary words, which will usually already provide him a lot of accounts, but furthermore he will then automatically apply to these potential passwords a set of frequent transformations wrongly perceived as secure by a lot of users.
Some password cracking software allow to accelerate the hashing process by using the GPU (the graphic card processor) which happens to be quicker than the CPU for the cryptographic operations required to compute some hash (the effectiveness heavily depends on the exact hash algorithm used, modern recommended hash algorithm are specially thought to fight against this).

Such process will usually not allow to get all passwords from the leaked databases, but it will still allow to get a lot of them: all the weaker ones. So, if you use a strong password, and the website used a proper password hash method, then even in case of a database breach your password may still be safe


Why is accessing a remote database a security risk?

The only Security risk I can think of would be if one of the two servers where compromised and thus compromised the other.

Or possibly they are concerned about hosting content that they do not have physical control over.

But yes, I too suspect its a marketing ploy


What is the purpose of a Session Border Controller (a.k.a SBC)

Great question.

The SBC is actually intended to be both a firewall and a reverse proxy.  In modern days however, it's essentially just a reverse proxy and a middleman server to allow different varieties of SIP applications/codecs/devices to all work together.

In the days of old, public IP addresses were assigned to most machines, and the SBC would get a public IP.  It would then essentially act as the firewall for the VoIP phone system in place, using whatever software was built into the OS or the SBC stack to act as a firewall and do basic packet inspection.

However, in modern architectures we usually see a firewall placed on the network perimeter.  This firewall is usually a lot better than the one on the SBC and receives a lot more attention, updates etc; so it'd be a best practice to use your main firewall.  In this case, the SBC should be behind this firewall and ports limited to those necessary to forward through.

The SBC may also carry additional layer-7 packet inspection; such as validating the VoIP traffic and getting rid of packets that might carry known exploits or other tricks such as spoofed caller ID.  Still, the layer 2/3 stateful firewall should be elsewhere and traffic forwarded to the SBC so it can do its layer-7 validation and inspection.

In the modern day and age I wouldn't recommend exposing an SBC to untrusted networks without a firewall in front of it; and if necessary I would do so within a DMZ or other isolated VLAN for the VoIP environment.


I found answer

[List.Rules:Pass]
   /?l <6$p$a$s$s$w$o$r$d


Why does DKIM verification succeed with a signature from Yahoo when all headers are spoofed to look like GMail?

Can't be sure without seeing the headers, but my guess is that from/reply-to/return-path are all spoofed and just handed in by the attacker as part of the SMTP transaction. As you said, the HELO is from yahoo, and it is yahoo which signed it. Yahoo isn't attesting to the value(s) of any of the headers in the transaction, just that it was injected into a yahoo server, which then dutifully DKIM-signed it, on behalf of yahoo, and off it went.

As to why OpenDKIM doesn't indicate phishy-ness when Return-Path and DKIM domain don't match, that would be a question/bug-report for the OpenDKIM folks to answer. Again, my guess is that it's only checking the domain of the MTA sender, against the DKIM signature, which will match.

I agree that seems to be a bug.


Can anyone access my computer if I use tor browser?

The TOR browser bundle is just one piece of (fairly) complex software and thus will contain bugs. It is based on the Firefox browser which regular receives bug fixes, even for remote code execution and this bug allowed an attacker to access local files in Firefox (but not TOR browser).

If it is possible to such bugs reside in a currently fully patched version of the TOR browser bundle but is not publicly known and I'm sure you will not get such information from the agencies which will use these bugs in the context of attacks or investigations.

Thus it is the best to not only use the TOR browser bundle but also use it from a system with no sensitive data on it. Also the system should not be able to reach any possible vulnerable systems inside your local network, because then typical Web 2.0 attacks like CSRF, XSS... in these systems could be used, like attacking the router or attacks using the local printer server.


Can a MAC be used as an irreversible PCI Token?

There is a specific tokenization guideline available in order to better understand the requirements and constraints of PCI-DSS in this regard.

This guideline specifies that there are different approaches regarding tokenization, being one of them "A one-way non-reversible cryptographic function (e.g., a hash function with strong, secret salt)". In addition, it allows a token format like 6+(Tokenized Value)+4.

In your scenario, from what I can ascertain, as long as the salt value used for your MAC-CBC is kept secret and unpredictable (thus making infeasible a bruteforce / collision attack in order to obtain the full PAN), you should be good in the eyes of a QSA.


Is this vault-less password manager/generator design safe?

The master key must be a sufficiently long, randomly-generated key. It must be at least 16 bytes generated uniformly at random (not 16 random printable ASCII characters and definitely not a human-chosen password or passphrase). Otherwise it would be possible to find the master key from any of the derived passwords.

This means that the master key is not realistically memorable by a human, so this scheme is not really vaultless.

If you use HMAC as the hash, then it's ok if the master key is not generated uniformly at random, but it still needs to have sufficient entropy to make a brute force search infeasible. For example, with Diceware, you need 10 words to reach 128 bits of entropy. Given that you'd have to change all your passwords if the key is ever compromised, don't settle for less.

Generating different keys from a master key is called key derivation. You're using a MAC as a key derivation function. This is probably ok with MAC that are used in practice, but it's dodgy. Any MAC guarantees that there's no way to find the master key from any number of (input, output) pairs, except for a brute force search over the set of permitted master keys. A MAC also guarantees that there's no way to find the output for a particular input without knowing the master key, even knowing the output for some other inputs. What a MAC does not guarantee is that there's no way to find the truncated output, and password length limits may require you to truncate the output. Rather than using a MAC, use a recognized KDF, such as HKDF (which is very easy to implement on top of HMAC, if your crypto library doesn't have it).

You could replace the MAC-should-be-KDF step by a password-based key derivation function such as scrypt or Argon2. This would let you use a master key with less entropy. Password-based key derivation functions are designed to take a password as the secret input and compensate for a smaller input space (less entropy than a normal-sized key) by being intrinsically slower to compute. For example, if the stretching factor makes it 1 billion times slower than HKDF (so it takes about 1 second on a PC) then it's enough to have 7 Diceware words (giving you 120 bits of entropy). Keep in mind that in this scheme, you won't be able to upgrade the stretching factor without changing all your passwords, so choose it conservatively.

The “quality assurance” step is badly named since it (slightly) decreases the security. It doesn't separate “weak” from “strong” outputs: all outputs have exactly the same strength. The strength if the output comes from how the output was generated, not from what it is. Call it an “output constraints” step, with outcomes “acceptable” and “not acceptable”. Note that you'll need different acceptability rules for every site (for example some sites insist on the presence of a punctuation character while others reject all punctuation characters).

Remember that you'll sometimes need to change your password on a site. So you need an additional public input “version” in addition to the site name. Make sure that the site name, the version and the counter are combined unambiguously. For example, plain string concatenation would not be ok since example.com123 could be version 1 with counter 23 or version 12 with counter 3. If you use printable strings for the site name, version and counter then you can concatenate them with a null byte as separator. You may also want to include a user name in there to support multiple accounts on the same site.

A practical limitation of this scheme is that you must only ever input the master key/passphrase on a system that you trust. This means only your own PC, only in circumstances where nobody might be spying on you (for example, not in view of security cameras). In particular, there's no way to create a password in a low-security environment and later upload it to your keyring. Every password must be generated in a high-security environment.

Since you need to carry your own PC to use this scheme, it is of limited benefit compared to a password vault. The only benefit is that if your PC is stolen while it doesn't have the master key in memory, you haven't leaked any secret. Balance that with the risk that if the master key is ever compromised, you've instantly compromised all of your passwords.

This scheme, if implemented correctly, is theoretically safe, but doesn't work well in the real world. It's well-protected against cryptographic attacks, but poorly protected against “out-of-band” attacks such as a physical keylogger, a keylogger malware or a security camera, or against revealing the master key through coercion or by accidentally typing it in the wrong field.

Your scheme is basically a single-factor authentication (only the master key) where a password vault is two-factor authentication (the vault content and the vault unlocking key). Two factors are more robust than one. A vault protected by a strong password is just as resistant to all the same attacks as your scheme, and additionally resists attacks such as shoulder surfing.

In terms of usability, both schemes require you to use your own trusted PC. Your scheme has the advantage that you can buy a new PC, retrieve your software from a trusted source, obtain an offline copy of the master key, and get access to your passwords. A vault requires the extra step of downloading the encrypted vault, but this is hardly ever a problem in practice: when would you need passwords but no have Internet access? As mentioned above, a vault has the advantage that it works in a common scenario where you want to create a password in circumstances where you don't have access to your PC, for example to create a password for shared work/personal use (e.g. a password for a travel-related site if you travel for work) on a work machine and then copy it to your personal vault.

I would strongly recommend a password vault over this scheme. It's more robust in real-world use cases.


For finding a wireless camera, people have long used "bug detectors" to hunt for unwanted RF transmitters and other electronic devices that unintentionally emit RF. There is no reason they wouldn't find an actively broadcasting Wi-Fi device.

For a wired device, use a tone generator and detector (often called a fox and hound.) Clip the fox to the first wire plugged into a switch, and start tracing it with the hound. Once you've found its terminus, move to the next wire.

A physical problem requires a physical solution.


Java is fine for servers. The security issues with Java are actually issues with the Java applet model, in which your JVM (in your browser) is meant to run potentially hostile code (i.e. code "from the Web") and yet somehow prevent that hostile code from doing bad thing. The applet model is a bit like running the applet code in a virtual machine, except that the isolation layer is done with the language itself and with safeguards in the standard library. It turns out that trying to do a sandbox that way is very hard, because you have to include explicit controls in every potentially dangerous library class and method, and there are thousands of these. All the Java vulnerabilities which have hit the news in the last years are about that: some standard library code which did not filter calls with enough robustness, in case the caller is an hostile applet.

None of this applies to Java on a server. On a server, that's your code, presumed non-hostile, and with full access to the standard library. Running Java code on your server is no worse (for security) than running C or C++ code; actually it is arguably better because the inherent protections of the Java language (garbage-collector based memory management, strong types and array bounds checks) make it more robust with regards to some categories of bugs like buffer overflows. Namely, consequences of a buffer overflow are more constrained (the buffer is not actually overflowed; an exception is thrown instead), and the GC allows for much easier handling of character strings, something which is a fertile source of buffer overflows when writing C code.

The same reasoning applies to .NET and its various languages (C#, VB...).


It's been nine days with no other answers, so I'll put in this poor attempt.
As a note, your references to both "master key" and "master password" are a bit confusing.

Start by looking at the john-dev mailing list entry on FileVault cracking; in particular, that post lists VileFault which may be of some use to you, and  Openciphers appears to have an FPGA FileVault implementation if you have a budget.

Also, Jeremiah Grossman had perhaps a similar problem.

Peachpit has an article that has guidance on resetting the master password assuming you know the FileVault passwords, if that helps you.

The actual encryption key should certainly be in RAM when you're able to decrypt the files - can you see what areas of RAM are being accessed every time you read files?

Last, I assume simply copying them all off to an external drive and then back to a fresh partition isn't suitable, since you mentioned "installing" everything again?


In a VICE interview Snowden removes a mobile phones internal speakers, then plugs a headphone set in when he wants to actually have a conversation.

Short of precision de-soldering you could try to jam it up with something, I don't believe new microphones in laptops and mobile phones have a diaphragm but you could at least muffle the speaker by pushing glue up against it.

Some laptops and mobile devices may on a hardware level disable the on-board microphone when an external line in is plugged in to the microphone jack, so you could plug in a dummy microphone to stop it listening.


Why are user names generally not stored in session cookies and provided with session IDs?

A session id is a temporary password which is usually linked to a username. Anonymous sessions are also useful tools in some cases.

Storing the username on the client serves no useful purpose. If the server trusted this information then it anyone could gain control by changing their username cookie to 'admin' or root'. Hence the session id does identify the user as well as proving the state of authentication, but only via an indirect lookup stored on the server.

In addition to anonymous sessions, it's also worth noting that the session data may be more than just a username and authentication state - it may also contain authorization information (e.g. roles) user preferences and (within bounds) transactional information. Storing information securely is not easily done on a substrate which is not protected against tampering.

I don't understand how you think this makes session hijacking / fixation more difficult; you've not explained why and you have some misconceptions about the way sessions work.

Certainly if the cookie data was trustworthy, then it would be easy to associate the true identify of an attacker with the http requests however the data is NOT to be trusted.

There are other ways to map identities to requests at the webserver - most SSO implementations provide for populating the webservers notion of the authenticated user. The information can be pushed up from the application (e.g. mod_auth_memcookie) or indirectly via other vectors such as supercookies and browser fingerprinting.


Is it possible to see a packet before encryption?

With the availability of browser extensions, actually reading the traffic should be quite doable. If both the malware and web browser run as the same user (and therefore can write to the browser profile directory), then installation of browser extensions can be done relatively easily.

You can also open the Web Developer Tools, typically accessible by pressing F12 and visit the Networking tab. That will show you all traffic before it is encrypted and pushed onto the network.

The above methods are passive ways that do not interfere with communications. Active methods perform a man in the middle (MitM) attack and actually modify data before it gets forwarded (Tylerl describes an example with Fiddler).


An important thing to note about Vulnerability scanners such as OpenVAS and Nessus, is that not all of the things they report are easily exploitable vulnerabilities.

In a lot of cases all they are doing is providing information about a host which could be useful to the tester or attacker in understanding the system and allowing them to execute other attacks.

In this case what you're seeing is an enumeration of Windows services which are accessible via DCE, there's nothing in that finding to say that they're vulnerable, and what you're seeing is quite typical for a local windows server (if that port (135/TCP) is open to the Internet, that would be a bit concerning as that's rarely needed or a good idea)

Verifying those services would be most easily done by reviewing the services running on the host with appropriate credentials, and stopping/disabling any which are not needed for the operation of the service.

As to your second point, there is nothing in that output which would appear to clearly indicate that your machine is infected by a virus.


My server is being DDoS'ed with 13 gbit and my provider nulled my ip, taking down my server - what can i do

With rare exception when it comes to a ddos there isn't much that can be done from the attacked computer / network. Once the connection attempt has made it to anything you control the attack has already done its damage. You basically need to wait on your ISP to handle the problem and provide them with whatever assistance they ask for.

EDIT: As pointed out in the duplicate question this only applies to level 4 style DDOS attacks. There are a few options to shorten response windows which can help with level 7 attacks.


What's is Dalvik/2.1.0? (I saw this in a capture data by port 80)

Dalvik is a Java VM. The fact that your phone still uses Dalvik pretty much means it's old, and probably insecure.

  WhatsApp are using ports 80 and 5222. I can read the data of this port (I saw Dalvik/2.1.0 in a log of WhatsApp). Is this port safe and normal to use?

Port 80 is normal WWW. Port 5222 is somwhat well known, but not standardized like port 80. Communication to this port is not unormal, and does not indicate any problems.

  The port 5222 are not SSL, but I can't read anything in the log (the characters are not make sense). Is this safe? Can a program decrypt this?

Impossible to say without more knowledge about what you had. It may be binary data, encrypted or cleartext, or it may be anything else.

  In a data log, I saw "host: check.googlezip.net". Is this legitimate?
  Are all these captures normal? It seen a lot of TCP connection.

What you see is more or less normal. Modern smartphones has a lot of processes running, and tend to be rather chatty.

The biggest worry should be that you're running Android <5, which is ancient and is more or less guaranteed to have security problems. Apart from that, I wouldn't think twice about any of the things you saw.


Are there any exploits in Movable Type that allow the attacker to delete the movable type files?

There are a large number of known vulnerabilities in MT 5.12, but this one that allows command injection (i.e., anything you can run at the shell, it can do) stands out: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-0319


Is it normal for a merchant to claim an online transaction is card-present?

This could have been a dummy field on the form.

Card present indicates that both the card and the customer are present at the time of sale, most payment processors also charge lower fees if the card is swiped vs typed in.

That being said, when a card is swiped there is extra information on the magnetic strip that isn't typed in. Payment processors usually receive the raw data from the card, which they then use on their end to execute the transaction.

So either this form input is a dummy, or they're using a card processor that allows them to claim the card was present. If you could post a link to the merchants site, we'd be able to take a closer look at what exactly that checkbox does.

After examination of the site in question, it appears that they are using a payment processor named "Converge Virtual Merchant". Their documentation on processing transactions is available on their site, located here https://www.myvirtualmerchant.com/VirtualMerchant/download/transactionProcessingGuide.pdf

Quickly reading through it, it does state the merchant has the ability to mark the card as present for hand-keyed transactions. The payment site in question is locked to say the card was present.

PCI compliance is for storage and security of cardholder information. Because the payment portal itself is hosted by the processor, it appears that it is indeed PCI compliant.

That doesn't negate fraud though. While your card information is secure, it appears as if the merchant COULD BE attempting to commit fraud by marking all transactions as card present. Since card not present transactions usually have higher fees to account for their risk, the merchant would be defrauding the payment processor by applying the lowest fee and moving that risk onto the processor, in this scenario. However the allegations of fraud and its implications is something that should be discussed on the Legal StackExchange site.


Encrypting does not inherently make a file larger.

However, in practice, encrypted files are larger than their non-encrypted counterparts for a number of reasons:

Symmetric ciphers in current use have the property that every possible ciphertext can be decrypted to a plaintext, or in other words, if somebody tampers with the encrypted file, it can still be decrypted.  If you're encrypting a file, you usually want some assurance that the file hasn't been changed while you weren't looking, and this requires adding extra information in one form or another.
Most symmetric ciphers work on blocks of data considerably larger than a single byte (AES-128, for example, works 16 bytes at a time).  As a result, if the file isn't a multiple of the block size, you need to pad the end to fill a complete block.  There are ways (such as "ciphertext stealing") to do this without making the encrypted file larger than the original file, but just adding a few bytes of padding is usually simpler.
There are many different ways to encrypt a file.  It's often useful to add a header to an encrypted file describing how it was done (what algorithm was used, what tamper-prevention mechanism is in use, how the password was expanded to produce a key, and so on).  In theory, this reduces security by providing information to an attacker, but in practice, the increase in convenience outweighs any minor reduction.


Is it possible to DNS-spoof Exchange ActiveSync?

an expired SSL certificate means:

There is no more way to validate the authenticity of the certificate. (I can no longer tell if its correct, or replaced by an attackers).
All proper software will complain every time I connect with this service, which trains people to ignore the messages. So when an attacker does the same no one reports anything.
the way the certificate and key are made could be outdated. (a MD5 hash is easily to find an collision for, as example).
The longer a key is in use, the higher the changes of someone breaking or stealing it. To limit this certificate expiration was invented.
As for the money to replace the certificates. SSL certificates are no longer as pricey as they ones were. most single domain certificates are below €10,-
an expired certificate also shows a lack of concern from management and IT. which undermines people's trust in the company.
etc...


What is the purpose of the Secret Key in MAC's ViewState ASP.net?

As you stated, the purpose of the MAC is to ensure the integrity of the viewstate data...The ensure that it hasn't been manipulated by the client.  If there were no secret key, this would not be possible.  If, say, a non-keyed hash function (take plain SHA-256, for example) anybody would be able to compute the hash.  This is very valuable when you want anybody to be able to compute the hash, say, to check the integrity of a downloaded file, but deadly if you want to identify if a client has modified some data since "anybody" includes "the client" and so a client could simply modify the viewstate, compute the new hash, send them both back to the server, and the server will get a modified viewstate with a hash that matches perfectly.

The secret key prevents this.  The key ensures that only the server, the holder of the secret key, will be able to correctly compute the MAC for any given viewstate.   So, even if the attacker modifies the viewstate, he will not be able to correctly compute a new MAC, and validation will fail, letting the server know that something is wrong and the request should be rejected.


First of all, I always prefer MITMF tool to practice a "Man In The Middle Attack".

In addition, monitor the network traffic during the attack using Wireshark to identify what is really going on in the network.

Moreover, you should make sure about DNS settings of your school. The DNS settings can be different between your home and your school. Large public areas such as schools, universities usually configure their own proxy and DNS settings. The difference in DNS settings usually the cause of "no internet" problem while trying a MITM attack.


Can we use CORS policy to restrict API calls from native mobile app?

CORS doesn't prevent anything, and it doesn't protect the server. It simply tells a conforming client (a browser) what is permitted for the protection of the browser's user; CORS is a way to carefully make holes in the browser's Same-Origin Policy. Additionally, CORS headers are advisory, in that they don't actually prevent anything from happening. They make it so that a malicious attacker can't fool an innocent victim's browser into making making certain requests (or, more often, using the responses to such requests) that the user wouldn't want the browser to make. A browser's user could, if it was wanted, open up the browser's dev console and make the request anyhow. Similarly, the user could export the request (cookies and all) to curl and - potentially after making more changes - send it from there.
Any non-conforming client (such as in a mobile app, or just a shell script invoking curl), can and usually will completely ignore CORS. Such clients don't have a Same-Origin Policy to begin with, so there's nothing for CORS to make holes in and therefore it does nothing.


Is the SD card write protection hard-wired or optional?

Wikipedia is correct: on SD cards, you have to trust the host system (whatever the card is plugged in to) to honor the physical write protect switch. Here is the relevant text from the publicly available specification documents. Emphasis is mine.

SD Specifications Part 1
Physical Layer
Simplified Specification
Version 4.10 January 22, 2013
4.3.6 Write Protect Management
Three write protect methods are supported in the SD Memory Card as follows:

Mechanical write protect switch (Host responsibility only)
Card internal write protect (Card's responsibility)
Password protection card lock operation.

Mechanical Write Protect Switch
A mechanical sliding tablet on the
side of the card (refer to the Part 1 Standard Size SD Card Mechanical
Addendum) will be used by the user to indicate that a given card is
write protected or not. If the sliding tablet is positioned in such a
way that the window is open it means that the card is write protected.
If the window is close the card is not write-protected. A proper,
matched, switch on the socket side will indicate to the host that the
card is write-protected or not. It is the responsibility of the host
to protect the card. The position of the write protect switch is
unknown to the internal circuitry of the card.