Using a CDN to reduce PCI DSS scope A common scenario for e-commerce credit card types of transactions is a website with a connection to a third party payment processor.  For a number of reasons you might not want to use an iFrame or page redirect, but doing so opens up your PCI scope significantly. Assuming the cardholder data would never be sent to your servers I would like to know if using a PCI compliant third party CDN (e.g. AWS CloudFront) would reduce your PCI scope regarding infrastructure significantly?

Take this example; a merchant's website consists of one html file that contains a form for collecting a customer's information and their credit card details. When the customer has filled in the details and presses submit the credit card data would be sent to the third party processors directly from the browser via an ajax POST, and receives a token in return. The token and other data is then sent off to the merchant's server, of course excluding any cardholder data.

Assuming the website is the only in scope system it would seem like a lot of the PCI requirements would no longer apply. It would be segmented by default, the CDN provider would take care of antivirus and IDS/IPS, you can't SSH into it, there are no internal services like SMTP, the firewall configuration would be greatly reduced or removed (since there may be only one port in and out)...I'm sure there's more.

Of course you'd still need to ensure the code is written in a secure way, have penetration test, and there are many other requirements that still apply, but at first glance this seems like a very secure solution, like a sealed box, that could greatly reduce scope.

Questions:

For the example above what will the scope be? Just the CDN distribution? The origin? The development computer used to upload the html file?
Will it be a problem if you can't monitor/log the low level traffic yourself? I guess the CDN will be responsible for that.

Edits:
I changed the question from iFrames to using an API as that seems more useful, as often using an iFrame will reduce a merchant to SAQ A unless you're a service provider.

Yes, moving card holder data (CHD) handling off of your network to PCI compliant 3rd parties is an excellent way of reducing the PCI scope of your implementation. Having the payment page hosted with a PCI compliant 3rd party, and integrating the transmission of CHD to a PCI compliant 3rd party tokenization and secure storage service provider, greatly reduces your PCI scope.

Note that you are still transmitting CHD from this site. So while this implementation would reduce your scope, the integration code would still be in scope. You still need to protect against Cross Site Scripting (XSS), redirection hacks from the payment page to the 3rd party site, etc. I would recommend doing quarterly PCI scans with an approved scanning provider here.

However, I don't feel using a CDN to achieve is ideal.  While a CDN could work, it seems like the right technology for this kind of implementation. The origin server could be considered in scope, making its own PCI compliance an issue, and complicating the implementation.

Given that the requirement is to only work with PCI compliant 3rd parties for the payment pages, I would suggest using a PCI compliant service provider for hosting, like GoDaddy Quick Cart, for example.  With this service, you can get Level 1 PCI compliance for $9.99 per month, and can customize the payment page to handle the CHD, and interface with the tokenization provider.  I think you will have more flexibility with this type of hosted service, and still reduce your PCI scope.


How to protect against clickjacking attack but allow legit iframes? I'm aware of modern anti-clickjacking approaches, such as X-Frame-Options header or framekiller scripts. But all these tactics prevent content to be inside iframe. But what if there is a requirement for content to be in iframe, such as Twitter "Follow" button or Facebook "Like" button? How to protect such iframes from clickjacking?

Share buttons will often use an iframe to protect them selves from CSRF.  In this context CSRF and ClickJacking have an identical impact which is sometimes called "LikeJacking".   You have to choose to be vulnerable to CSRF OR you can use an iframe prevent CSRF but then you expose your self to ClickJacking. It so happens that ClickJacking is the lesser of two evils.  FaceBook solves this logic problem with Legal Action.   You can make "LikeJacking" and ClickJacking against your against your Terms of Service and sue them like FaceBook.

There maybe a technical solution to this problem. I emailed Google Security on this topic and they said that they where using "Signal Analysis" to determine if behavior was taking place.  Which is a pretty gaseous answer to say the least.  Being Google they do spider all of the pages that are liked,  and they could determine if a clickjacking method,  such as an SVG mask was applied to their iframe by the parent page.  But this is just speculation.


Pre-paired hardware security tokens - Why don't they exist? I've had this idea bouncing around in my head for a while, and I'm honestly surprised that it doesn't seem to be on the market. Which probably means that it wouldn't work well for some reason that hasn't occurred to me yet.
I think it should be possible to buy hardware security tokens (Yubikey etc.) in pairs, with each pair intentionally manufactured to share a secret. That way you could seamlessly switch back and forth between them. This would make the "main key/backup key" pattern much more usable, because you wouldn't have to manually enroll both keys in every account where you want to use 2FA.
Currently this requirement makes it impractical to truly treat your backup key as a backup. It works well enough if you lose/break your primary key, but isn't helpful if your house gets burned down/flooded/whatever, because it's simply impractical to store both keys anywhere other than your home. Moreover, having to enroll two security keys for every account is pretty inconvenient, and as we all know, "security at the expense of usability often comes at the expense of security."
One downside is that this would effectively double the cost of the token, because as soon as one of your paired keys is broken/lost you have to ditch the other one and get a new pair. However, nothing says this has to be the only way in which security keys are sold, and I for one would be happy to pay the extra $40 or whatever a Yubikey costs for the extra convenience/peace of mind. Not to mention, the manufacturer could increase their per-customer sales, which seems like it would be good for them.
However, it doesn't seem possible to buy pre-paired keys like this. Why not?

Having duplicate keys would make manufacturing a bunch trickier, because you have to create exactly two duplicates and then sell them together.  If you accidentally sell a pair of keys that doesn't match, then you've caused a security nightmare, since neither of them can be securely used (since someone else can have the same key).
Also, most security tokens contain a counter of uses and reusing the counter repeats the secret.  For example, a YubiKey's one-time password has a counter as part of the message.  Thus, a second key would be detected as a replay attack and rejected by many sites.
What you want to do is possible using DiceKeys, which is a way to generate a secure 196-bit secret that can then be loaded onto one or more special SoloKeys.  Having a programmable key is easier than providing multiple keys, since the user can program as many keys as they like.
However, as mentioned, in order to support this use case, the special SoloKeys always use a fixed counter of zero, which works for most FIDO2 and WebAuthn applications but wouldn't be usable for OTP use cases.


Could I XSS a page that filters &,", characters and has Content-Type set to UTF-8? I am trying to pentest a dummy website that has a form with a TEXTAREA input on one page.
When the form is submitted, the contents of the form are displayed on a second page.

However, the second page that receives the POST input, filters it to replace ", <, > and & with &quot, &lt;, &gt; and &amp;.

The second page also has a:

<meta http-equiv="content-type" content="text/html; charset=utf-8" />

I used Fiddler to intercept the POST from the first page and modified the request header fromContent-Type: application/x-www-form-urlencodedto:Content-Type: application/x-www-form-urlencoded; charset=UTF-7

And changed the POSTed content to:+ADw-/font+AD4APA-script+AD4-alert(document.cookie)+ADw-/script+AD4

Hoping that it would decode to:
</font><script>alert(document.cookie)</script>

However, it didn't do anything and text showed up as it is. Also, the text-encoding of the second page was recognized as UTF-8. I guess that's because it has a meta tag in it's HTML with the charset set to UTF-8.

I want to know if there's a way this page can be exploited through XSS and if there is, what would be the input vector?

The OWASP XSS Experimental Minimal Encoding Rules suggest that all that needs to be encoded are <, & and >, as long as the charset is specified.

Assuming the second page outputs within an HTML context, then there doesn't seem to be an XSS attack vector in this case.

Setting charset and then encoding your POST will simply mean that the server will interpret it as such, converting any text into its own internal representation (assuming no flaws exist in the technology stack the site is using and everything is doing its job properly). So when it is output, the characters will be encoded again meaning your attack fails.


What is the best solution to encrypt pagefile? I want to encrypt my pagefile.sys. I do not need to access information from it, so I don't need the encryption key after restart. I have these four alternatives:

AES-256 key in Cipher Block Chaining (CBC) mode
Blowfish-448 key CBC mode
Gost-256 key in Cipher Feedback Mode (CFB)
Twofish-256 key CBC.

So which is the best choice? I dug on Google, and my opinion is 4. Expert opinion?

Encrypting the pagefile implies you're wanting to protect against someone taking the file after gaining physical access, which is best dealt with by whole disk encryption. If an attacker has access while the os is in operation, the pagefile is neat to go through for historical purposes but otherwise juicier targets abound. If the purpose is to clean tracks after having used a ton of ram, then you're better off using a cleaner tool of some sort (yeah that's vague, you figure it out) to selectively edit/overwrite.


When is an email rejected? Currently, I am working on a web application and wanted to let users send emails to others through a web form. So, they just should submit their email address and my web app would then send mails to others with their email in the FROM header.

Well, now I learned that this is not a good idea because those emails will most likely be rejected. However, I do not yet fully understand it.

Basically, there're two technologies that are widely used to prevent spam and spoofing: DKIM and SPF.

What I read so far does SPF check the Envelope From header.

Now let's assume a user wants to send an email to others using my web application. So, the user wants to use bob@example.com as his sender address. Now, my web application will put this address to the FROM header and send the email using my own email server to the recipients. Because I'm using my own email server, the Envelope From header should be my own domain, i.e. mandy@thedomain.com.

As said before, SPF checks AFAIK the Envelope From (MAIL_FROM) header. So the recipient's server will ask my DNS and check if the corresponding IP addresses are allowed to send mails as bob@example.com. That's possible, so the mail should not be rejected.

Summarizing, so far everything should work (if I understand it correctly). But now let's look into DKIM.

And here's what I do not understand. I know that using DKIM on my mail server will sign the email and the recipients will check using the public key that is pointed to in the DNS.

However, what do they look for? Do they look for the Envelope From header again only? Then it should work again, no? Because the email is signed using my private key and the recipients will also look for my public key in the DNS.

Or is DKIM looking for the FROM header? Then it would not work because I cannot sign the email with a private key found on the DNS for bob@example.com.

Unfortunately, I have not yet found exactly WHEN an email is rejected using DKIM. I hope someone can help me! Thanks a lot.

DKIM signs the From: header and optionally other headers.  You can specify which headers in the DKIM header itself.  The envelope From isn't signed.  DKIM and SPF are both used as one means among many when evaluating if a message is spam/a joe job.  Bear in mind that you are trying to do exactly what spammers do - send e-mail from an address that isn't yours so you are likely to get blocked by things designed to catch spammers.


Is the OWASP recommendation regarding localstorage still valid? I am currently working on an Application which is a single page application built with Angular. It is served over HTTPS, using HSTS.

For authentication, we are using Auth0. The Auth0 documentation recommends storing the access token in localstorage.

An interceptor is then used to add this to the header of each HTTP request.

However, this answer recommends not storing any sensitive information with localstorage.

The answer is from 2011, and the author also co-wrote the OWASP HTML5 cheat sheet, which states:

  Pay extra attention to “localStorage.getItem” and “setItem” calls implemented in HTML5 page. It helps in detecting when developers build solutions that put sensitive information in local storage, which is a bad practice.

I am wondering if the situation in 2017/2018 has changed. Am I OK to follow Auth0's guidelines, or should I take another approach?

Personally I see no issue with using local storage as long as you are happy with the user not having to re-authenticate between sessions. The linked answer provides the following argument against this. I would argue it is very weak -

  Underlying storage mechanism may vary from one user agent to the next. In other words, any authentication your application requires can be bypassed by a user with local privileges to the machine on which the data is stored. Therefore, it's recommended not to store any sensitive information in local storage.

This applies with any kind of authentication token. Someone local with admin privileges (assuming its not encrypted with a key tied to the users credentials) can read it out of any kind of storage, RAM or maybe even straight off of the network.

He also suggests -

  (or XSS flaw in the website)

Again - this applies to any kind of token that the JavaScript can access.


What is the difference between serial number and thumbprint? I have problems to understand what is the difference between the serial number of a certificate and its SHA1 hash.

The MSDN says:

  Serial number   A number that uniquely identifies the certificate and
  is issued by the certification authority.

So can I identify a certificate by its serial number, right?

Wikipedia says for the hash:

  Thumbprint: The hash itself, used as an abbreviated form of the public
  key certificate.

So the hash identifies the (e.g. RSA) key.

I currently do some research on Android app certificates and I found some interesting certificates:

[Issuer][Serial][SHA1 Hash][Valid From]
[C=US, L=Mountain View, S=California, O=Android, OU=Android, CN=Android, E=android@android.com][00936EACBE07F201DF][BB84DE3EC423DDDE90C08AB3C5A828692089493C][Sun, 29 Feb 2008 01:33:46 GMT]
[C=US, L=Mountain View, S=California, O=Android, OU=Android, CN=Android, E=android@android.com][00936EACBE07F201DF][6B44B6CC0B66A28AE444DA37E3DFC1E70A462EFA][Sun, 29 Feb 2008 01:33:46 GMT]
[C=US, L=Mountain View, S=California, O=Android, OU=Android, CN=Android, E=android@android.com][00936EACBE07F201DF][0B4BE1DB3AB39C9C3E861AEC1348110062D3BC1B][Sun, 29

And there are a lot more which share the same serial, but have different hashes.

So there can be a certificate with different key? Who is actually creating the serial number when creating a certificate for an Android app? For the hash it is clear, but can I create a new certificate with the same serial number as another cert?

Can I be sure that a certificate with the same serial number was created by the same person?

In a certificate, the serial number is chosen by the CA which issued the certificate. It is just written in the certificate. The CA can choose the serial number in any way as it sees fit, not necessarily randomly (and it has to fit in 20 bytes). A CA is supposed to choose unique serial numbers, that is, unique for the CA. You cannot count on a serial number being unique worldwide; in the dream world of X.509, it is the pair issuerDN+serial which is unique worldwide (each CA having its own unique distinguished name, and taking care not to reuse serial numbers).

The thumbprint is a hash value computed over the complete certificate, which includes all its fields, including the signature. That one is unique worldwide, for a given certificate, up to the inherent collision resistance of the used hash function. Microsoft software tends to use SHA-1, for which some theoretical weaknesses are known, but no actual collision has been produced (yet). A collision attack on SHA-1 has now been demonstrated by researchers from CWI and Google.

(The thumbprints you show appear to consist of 40 hexadecimal characters, i.e. 160 bits, which again points at SHA-1 as the plausibly used hash function.)


How does OWASP rank the top 10 risks? I was reading articles about OWASP A2 (2017) and the found below comparison chart. One thing I noticed was that "Broken Account and Session Management" has changed place over the years:

In 2003 and 2004 it was A3.
In 2007 it was A7.
In 2010 it was A3.
In 2013 and 2017 it is A2.

What is the reason for this?

(Original source from which the image was generated is unknown.  Google reverse image search https://images.app.goo.gl/haEq2nxGjKYzgWrR9 shows that a more complete image that includes footnotes is at https://goldcrock.wordpress.com/2015/02/ - but it's unclear where that was originally sourced.)

My understanding is that they are rated on the prevalence of that specific risk in the wild.

This is explained in the introduction to OWASP top 10 here

  Welcome to the OWASP Top 10...reorders some of the others based on
  changing prevalence data.

So A1 is more common in the wild than A2 and so on.


Comply with data protection requirements without giving away too much? I'm a contractor for a few companies. I build and host their systems on servers I rent from a popular international host. I store the system code on a popular, internationally hosted version control system. There are a mix of authentication techniques at various points, most of them near-best practices.

However, I also layer on some obscurity. SSH is hidden, some things are encrypted in non-obvious ways. Alone these wouldn't be valuable but alongside the real security, I fend off most serious threats.

One of my clients got a data protection process request from one of their clients today: a huge government organisation. They obviously take this red tape stuff pretty seriously and have sent us a long questionnaire that asks for specific security detail. Not just about the data we collect but also where it's secured, how it's secured, where the locks are and who has the keys.

The last few of those things are the sort of stuff I keep hidden from my clients, not to mention theirs. As the person with all the keys, I'm very conscious of this overused but accurate comic:

Currently my clients' clients don't know about me. Not really. But if we comply with their request, anybody with access to this request, suddenly knows who I am, where I am, what I have access to. If you wanted to break into their portion of this system, you come after me.

And you can go deeper. Part of this request mentions Access Control Policies and gives an example that explains where (exactly, geographically) a private key is stored. If you follow this through every system that tangentially touches the data they submit, they have a map of every system we use and know who to come to (or hack) to gain access to the whole thing. It unsettles me.

My question is, in your experience, is there a way to comply with security procedure requests that doesn't target specific people, computers or even ports?

Very little of this stuff is actual legal requirement. We already meet data protection act guidelines... But again, being a large government agency, their drive to tick boxes seems several powers greater than any other organisation.

Just a couple of clarifications.

My client has details on the system. They have no direct access to server operations. They have access to the version control system and receive encrypted data backups on a very regular schedule and have a document (and encryption keys) that explains how to replace the system I run with one of their own in the event of my untimely demise. We have discussed the overview but the exact details are under physical lock and key.
We aren't dealing with launch codes. Names, contact information and IP addresses. I didn't expect this would be relevant to the question but people are bringing up the two-man rule. That's way over the top here. This is technically sub-PCI-DSS.
I am developer and operations for this small company (as well as others). Many of you are talking about me being the weak point. I am. One wrench and you have the data I have. That's why I'm asking.

Please, rather than just pointing this out, some suggestions on what to do about these things on a small scale would be more useful. I can't be the only devop on the planet who tangentially deals with governments.

The request for this information may not only be for a security audit, but also a process audit, and it sounds like it might be well founded, since:

  If you wanted to break into their portion of this system, you come after me.

What would happen if you were "hit by a truck" tomorrow? If you are the only one that knows the systems, your clients and theirs would certainly have a big problem. Ideally, someone else needs to have access also, and it should be documented who that is and how to contact them.

Depending on the requirements, it may be possible for the holder of the keys to be a company rather than a person, perhaps with a primary and secondary contact named. The primary contact could likely also be someone at your client, and they probably should have all the documentation for how to access their systems in an emergency if you are not available.

Also, you may be able to provide a report with certain things redacted. They likely are more interested in knowing that the non-redacted documentation exists somewhere and that the proper people have access to it when needed. They probably won't care that the port numbers, etc. are blacked out, as long as they can be sure that they exist in a document somewhere.


encryption method against man in the middle attack Let's say there are 3 computers: Alice, Bob, Carol. Carol is network provider, so everything from Alice to Bob and vice versa passes through Carol. Carol can modify messages between Alice and Bob. Is there any algorithm or method for secure communication between Alice and Bob, even if Carol can modify packages? For Diffie-Hellman I found this:

  Roughly speaking, the basic idea is as follows. Prior to execution of
  the protocol, the two parties Alice and Bob each obtain a
  public/private key pair and a certificate for the public key. During
  the protocol, Alice computes a signature on certain messages, covering
  the public value ga mod p. Bob proceeds in a similar way. Even though
  Carol is still able to intercept messages between Alice and Bob, she
  cannot forge signatures without Alice's private key and Bob's private
  key. Hence, the enhanced protocol defeats the man-in-the-middle
  attack.

Can anyone explain with example?

Edit:
A is client, and B is server, A uses login/password to authenticate.

You need a definition. Namely, what is "Bob" in Alice's view ? If "Bob" is "whoever responds" then Carol would make a nice Bob -- in that case, there is no real attack, just Alice talking to "someone" who happens to be Carol.

If there is a definite notion of Bobness that Alice can use, then there are algorithms which build on that. That's how SSL works. Imagine that you are Alice, Bob is a Web site that you know by name (e.g. "www.paypal.com"), and Carol is your Evil ISP. You do not want to talk to just anybody, you want to talk to a specific Bob/server that has a name. Public key certificates can use signatures to give you some guarantee over the binding between the name ("Bob", aka "www.paypal.com") and a public key: the guarantee provided by the whole system is that a given public key is really "owned" by an entity who bears the name "www.paypal.com", where "owning" means "having exclusive control of the corresponding private key", and in a way that Carol cannot obtain a similar guarantee.

Once there is a known server's public key, the key exchange can be protected against MitM. Again, see how it is done with SSL.

In the case of X.509 certificates, Alice must have an a priori knowledge of a root certificate authority public key (here "trust anchor"). For another model, consider SSH. Here, we assume that Alice could establish, at some point, a Carol-less connection to Bob (or a connection that Carol did not bother to alter). Then, Alice remembers Bob's key, and uses it again for all subsequent connections. That's how SSH usually works: for the first connection, the client requests explicit user confirmation, then stores the public key in Alice's .ssh/known_hosts file. Ideally, for the first confirmation, Alice would verify with some out-of-band mechanism the server's public key (its fingerprint) before accepting it the first time (e.g. by making a phone call to the server sysadmin, and checking with him the key fingerprint).


Are auto complete forms a security concern? I know when I fill out forms with address and email it will attempt to auto complete the rest of the information.  Is it possible to include more hidden fields on the page in order to get more information with the auto complete than is visible to the user?

A real life example.  I recently filed my taxes online which included my social and that made me think if this.  Obviously a website should prevent saving of confidential info, but if those measures weren't in place could another site where I'm simply putting in my email secretly auto complete more info not visible like my social?

Frankly, yes, there is an issue.

Assuming, of course, that your browser is auto-completing forms, it's possible that it will happily populate any applicable field it sees, whether you can see it or not.

That's why it is important to keep your auto-complete tool clean. Packages like LastPass add a large red icon to fields it auto-completes so that it is very obvious when it is adding data.


Is .UtConfig folder spyware? I have a dozen or so new files as well. I am pretty certain the alvin file has something to do with spyware.

If I remember correctly, this folder is created by apps than contain ads created by TaoBao. Alvin2 seems to be regenerated, even if you delete it, by the same apps that create .UtConfig.

They have been existing for quite a long time and the .xml doesn't seem to cause any trouble


How can I be protected from pictures vulnerabilities? I've just read this question What is the corrupted image vulnerability? How does it work?
(GIFAR, EXIF data with javascript, etc..)

I'm asking myself how can I protect myself and my website's users.

My users are allowed to upload their own images (e.g. forum avatars, pictures as part of a message), these pictures being displayed to all other visitors of the corresponding page.

What can I do to be sure that an uploaded file is a real, plain picture and not something else? I'm not asking about a way to overcome specific vulnerability, I'm asking how can I be sure that file contain nothing else than a plain image data? (so I'll probably be protected also against 'yet to be find' vulnerabilities)

I have some suggestions:

Use a separate domain. Host the images on a separate domain that is used only to host user-provided images.
This will ensure that many browser-level attacks can have only limited effects.  For instance, suppose the user's browser is vulnerable to content-type sniffing attacks, so it is possible to upload an image that some browsers will treat as HTML containing malicious Javascript; this defense ensures that the malicious Javascript can only tamper with other user's images, and cannot access your site's cookies or content or other security-sensitive stuff.  However, this does not defend against code-injection attacks that exploit a vulnerability (e.g., a buffer overrun, a double-free) and execute native code.

Defend against content-type sniffing.  Follow practices I've outlined elsewhere to defend against content-type sniffing attacks.  The most important one is to set a correct Content-Type: header on the HTTP responses where you serve the image.  It can also be helpful to include a X-Content-Type-Options: nosniff header, to prevent some versions of IE from trying to do content-type sniffing.

Convert to a fixed format. Convert the input image to a bitmap (keeping only the bitmap data, and throwing away all the extra annotations), then convert the bitmap to your desired output format.  One reasonable way to do this is to convert to PBM format, then convert to PNG.
This is not a reliable way to stop attacks, but it reduces some of the attack surface available to the attacker.  For instance, it prevents the attacker from attaching malicious metadata that are crafted to exploit some vulnerability in the image parser.  It also does not give the attacker a choice of image formats.  To defeat this defense, the attacker must find a vulnerability in the PNG decoder, in the code that reads image pixel data.  It prevents the attacker from exploiting a vulnerability in the decoder for some other image format or in the part of the PNG parser that reads metadata.  So, while potentially helpful at reducing the risk, I would not expect this defense alone to be sufficient.

Consider randomization.  Consider inserting some random noise into the image.  For instance, you might loop over all the pixels, and for each of the three intensities (corresponding to RGB) for that pixel, randomly choose among adding 1, subtracting 1, or leaving that intensity value alone.  This introduces a tiny bit of noise into the image, but hopefully not enough to be noticeable to viewers.  And, if you are lucky, it may make some attacks less likely to succeed, because the attacker cannot fully predict the result of the transformation.  This defense is highly heuristic and is certainly not guaranteed to be effective, but it is possible it might help, if used in addition with the other defenses I've outlined, as a sort of belt-and-suspenders defense-in-depth strategy.  But please understand that this defense alone is probably not adequate.

Depending upon how concerned you are about these risks and the sensitivity of your site, you don't need to do all four.  If you are not concerned about code-injection vulnerabilities in the browser, you could do just #1 and #2.  If you want partial protection against code-injection vulnerabilities in the browser, you could do just #1, #2, and #3.


Bypass MAC address internet time filtering? My brother disabled my internet access for my devices from 10pm - 6am. The internet on his devices still work 24/7. I am still connected to the WiFi but there is no internet access because he did a MAC address time filter. I use my iPhone and my laptop.

Is there any way to get around this?

You can defeat your brother's access restrictions, either by a timing-attack or side-channel attack.

In a timing-attack, you wait for a sufficient time, your brother will remove the MAC filtering for your device.

If you cannot wait for the time-based attack to succeed, you can use a side channel attack and connect to the internet via an alternative channel, such as GSM or a friendly neighbor.

Joke aside, MAC spoofing is a way to overcome MAC filtering. Since MAC-filtering is (usually) only tied to the MAC-address assigned to a network interface controller, you can change your MAC-address to match the one of an unfiltered device. This is a relatively easy process, but can cause harm (Denial of Service), depending on network equipment and configuration.

On wired networks, switches are usually only designed to forward traffic destined MAC-address to one port. If multiple ports have the same MAC-address, the network logs might contain warnings of MAC-flapping and alert the administrator. This blog post demonstrate how the network can become unreliable for devices that share the same MAC-address.

On wireless networks, sharing the same MAC-address usually do not lead to the same problems as on a wired network. The reason for this is that the wireless network is a single network port (a single radio interface) with multiple connected devices. There are no alternative ports for packets to take as long as both devices are connected to the same access point over WiFi.

Sometimes, you also have to clone the IP-address of an unfiltered device (this is also dependent on the network devices that handle MAC-addresses). This can lead to another set of problems:

If your network adapter is set to DHCP, you might be issued the same IP-address as your target device.
You and the target device can get visual warnings about IP-address conflict.
Your and the target device might drop connections that belong to the other.

If possible, try to use statically configure the adapter to use an unused IP-address. If you absolutely have to also spoof the IP-address, wait for the device to disconnect from the network. There is a tool called CPScam that is used to bypass captive portals (which most commonly use MAC-filtering). This tool will monitor the network for active devices, and alert you whenever a device leaves the network. If you impersonate a device that is no longer on the network, it should not cause harm or alarms, at least not until it reconnects.


Apache Server Maintains HTTPS Connection To Mysterious Server (Hijacking?) I've been on a shared webhosting plan for 10 years and I recently moved all of my sites (various WordPress sites and associated plugins, all in PHP, a MediaWiki site, and a lot of static stuff) to my own VPS. Yay! Now I have no one to blame but myself for any problems relating to availability, performance, and security.

Regarding security, I was auditing 'netstat' output on this Linux-based VPS today and noticed that I had an established connection to port 443 (HTTPS) on a different server. I figured out what DNS name this IP address resolves to and hit the googles. This domain is only associated with monetary scams and fraud.

So this HTTPS connection is just hanging around. I visit the site and the root page is a small bit of JavaScript that collects some basic info about the user's browser and screen size and then redirects to a second page on the site that plants a cookie.

I ran lsof -i and determined that one of the Apache processes on my server has established the connection to the secure server.

Any idea what might be going on here? It seems pretty clear that something shady is happening. My best theory is that an attacker is hijacking an Apache process which, in turn, is dynamically requesting JavaScript via an encrypted connection and injecting it into outgoing pages.

Other data points: I have searched through all my files and can't find any trace of this DNS name or its IP address; however, I know that's not conclusive evidence because I've seen JS-based malware that can obfuscate URLs pretty easily. Also, I have checked all of my computers which have been accessing my various sites and I can't find any trace of the cookie that the JS would be planting (which could just mean I hadn't hit the suspect Apache process yet).

Always the programmer, I wanted to try to reproduce the problem, so I rebooted the server and I haven't seen the connection get established again.

I have some ideas about mitigation or tracking (block connections to the bad server, either via firewall or the /etc/hosts file; redirect HTTPS requests to my own system with a spoofed cert just to investigate the network transaction if the same circumstances arise again). It seems really odd that the connection was left open (when it could just fetch the page once and be done), but maybe this was an errant condition and it wasn't supposed to remain open.

Sorry if this is a lot of detail, or if I'm overthinking something simple. I'm just being paranoid about taking care of my little slice of the internet. I was hoping to see if these details set off any familiarity alarms.

I hate those kind of problems. There are so many places something could have happened.

I think I would just double check my config files - always a good idea to have a copy of valid config files. I use a GIT based tool to version all of mine. Then you can easily spot any unknown changes and back them out.

Then I would add the domain to IPTABLES and block it totally.


Is it secure to handle the OAuth 2 Authorization callback from a CDN? This question is in the context of the OAuth 2.0 Authorization Framework.

Consider a web application that is backed by a first-party API but relies on a third-party authorization server for SSO.

Say the index page for the application is hosted on some CDN like Amazon CloudFront.  The page invokes JavaScript that checks to see if there is an authorization code in the query string.

If there is no authorization code in the query sting, the page invokes JavaScript that redirects the user to the third-party login page.  After the user logs in and authorizes the app, the third-party server redirects the user back to the same index page hosted on the CDN with the authorization code in the query string.

If there is an authorization code on the query string, the page invokes JavaScript that makes a request to the first-party API that includes the authorization code.

The first-party API tries to get an access token from the third-party authorization server with the given authorization code and the predefined client secret.  If successful, it then tries to get the user resource on the third-party resource server. Then it responds to the request from the index page on the CDN with a session cookie for that user.

Now, in my experience, the redirect URI has been a resource on the first-party API, which redirects the user again, back to the index page on the CDN.  But for this question, the first-party API wants the index page to pass it the authorization code through AJAX.

Is this a secure workflow?  If not, how is it a result of using a CDN resource for the redirect URI?

First - as you wrote the third-party authorization server requires client secret known only to The first-party API - so only your back-end can actually exchange authorization code for access token - nothing wrong here.

Second - you should be using HTTPS for your redirection endpoint so make sure your CDN support it. Otherwise somebody can eavesdrop the exchange, submit the access code first and take-over user session.

Third - make sure You are using OpenID Connect provider or something similar if you want SSO. Plain OAuth is not designed for authentication (OAuth Authorization vs Authentication)

Last - unrelated to OAuth - you have to asses how putting you index page on CDN affect your application security. It probably improve your DOS protection but introduces element outside your direct control.


Randomness of hash of (password + suffix) Suppose I have a password, say "thisIsThePassword".
Then I have MD5 hashes of that password followed by an increasing numeric suffix:
MD5("thisIsThePassword1") = c5c038617ea97315f137606c4123789e
MD5("thisIsThePassword2") = 0a52caffe2e7904c832a257a406f903f
MD5("thisIsThePassword3") = 06683298a9c3cdf8940518db54c43758
...

The question is: are those hashes related to each other in any way, so that from one hash it is possible to compute another one without having to bruteforce the password? Hashes are supposed to be totally different and random as soon as you change one bit in the input, but I'm afraid there are some gotchas, maybe when comparing the hash of thisIsThePassword1 with the one of thisIsThePassword11 (and subsequent suffixes starting with "1"). Would it be better or make any difference if we used SHA instead, or make sure the input is always the same length? What function or method should I use if I wanted to make sure that you can't easily compute another of those hashes unless you bruteforce the password?

Most common hash algorithms are designed to produce outputs that are indistinguishable from random, and as a result, even related inputs are not supposed to produce related outputs.  Therefore, generating multiple hashes with related input isn't intrinsically insecure.  You can use KMAC (related to SHA-3) and BLAKE2b as MACs and they can be used securely with related inputs in this way.
However, MD5, SHA-1, and SHA-2 are vulnerable to length-extension attacks.  That means that it is possible, given a hash and the original length of the input, to produce more hash values with the same prefix without knowing about the original input.  Therefore, you would not want to use this approach with one of those algorithms, because an attacker could possibly compute and compare additional values to see if they match.  The SHA-3 algorithms and BLAKE2b don't have this problem.
If your goal is to hash a password, though, you don't want to use a simple hash function using any construction.  Passwords typically don't contain a lot of entropy, and so you want to use a good password hash such as scrypt or Argon2i with a large salt and suitable iteration count.  You can either create a new salt for each use or generate a single salt and append a fixed-length counter.
If your secret isn't actually a password but instead a randomly generated secret with enough entropy (at least 128 bits), then you're probably better off using something like HMAC with a strong hash function, or HKDF if you want a key derivation function.  You can then provide the secret as the key and the counter as the message to hash, and this will both avoid length-extension attacks and also has much nicer provable security properties.
And, of course, you would never want to use MD5 or SHA-1 for any purpose.  They are both broken and you'd want to use something like SHA-2 (if you don't need to worry about length-extension attacks), SHA-3, or BLAKE2b.


how can an attacker use a fake temp file to compromise a program? I am taking a security class. The class notes say that an attacker can observe a pattern in temp file names and then make their own temp file to compromise a program. They say that if a temp file is made using a process ID, an attacker could create a symbolic link
to a password ﬁle with a tripwire process ID so as to make the tripwire use the password file a temp file.

How could attacker use temp files to compromise a password file? Or to otherwise exploit a system?

The first thing to consider is what is the purpose of the temp file.

If the temp is outputting useful information, an attacker could use this to glean information about the functionality of the programs, settings, error messages, etc (depending on the output). The attacker may be able to have a malicious program occasionally scan such files looking for certain patterns to then use in attack logic.

At the same time, if the temp file is going to be read in, you can change the input logic of the legitimate program which is not tightly locked down. For example, if the temp file is going to be read in for the purposes of eval() or running a system() execution you can then make the program do something its privileges will allow on the system to do, that are not expected.

Instead of modifying the temp file which will be read in, it may be possible to create a symbolic link to another file that you as a user cannot access but that the application may have privileges to read. If the program prints out the temp file, you could expose it that way. It sounds like the attack being described in a privilege escalation, not a direct change to the password file.

Code Project: Security Tips for Temporary File Usage in Applications

  If the attacker knows where the application creates its temporary
  files and can guess the name of the next temporary file, the following
  attack can be realized:

  Attacker will put a symbolic link at the temporary file location.
  The attacker will link the symbolic link to a privileged file.
  Now, the application will unknowingly write to the privileged file instead of writing to the file in the temp directory.

There is also a CWE (CWE-377: Insecure Temporary File) for this, worth the read as well as some of the related instances:

  If an attacker pre-creates the file with relaxed access permissions,
  then data stored in the temporary file by the application may be
  accessed, modified or corrupted by an attacker. On Unix based systems
  an even more insidious attack is possible if the attacker pre-creates
  the file as a link to another important file. Then, if the application
  truncates or writes data to the file, it may unwittingly perform
  damaging operations for the attacker. This is an especially serious
  threat if the program operates with elevated permissions.


Risk of letting a complete stranger charge his smartphone on your laptop's USB port How risky is to let someone connect a smartphone for charging it?

Could someone intentionally or unintentionally contaminate a fully updated and patched Windows 10 or Ubuntu laptop?

You are basically asking what the risk of connecting an arbitrary USB device to your system is. Because: even if it looks like a smartphone from the outside it can actually be anything on the inside.

This specifically means that the device can physically destroy the USB port like the USB killer. It can also hijack your communication by emulating a network card. It can also emulate a keyboard, mouse or usb mass storage. And these attacks don't even rely on bugs in the operating system, there are likely more dangerous attacks using buffer overflows or similar in drivers (which run in kernel context) etc.


Is a SPA vulnerable to the BREACH https security exploit? I have a Single Page Application (SPA) that consists of static resources (HTML, JS, CSS, images fonts ...) that are served from an Apache web server and several API endpoints (serving JSON from a JBoss Backend, proxied through the same Apache that serves the static resources).

Client browsers have access to the SPA only via HTTPS.

Sensitive data is served exclusively from the API endpoints.

I would like to enable gzip compression for all the static resources.
gzip compression will not be enabled on the API endpoints.

Is enabling gzip compression on the static resources a security risk because of the BREACH security exploit?

I do not fully understand the BREACH attack:

My static resources (which would be compressed) do not reflect any user data
The API calls do reflect user data and can contain query parameters, but they are not compressed.

Is the above scenario vulnerable to the BREACH attack or not?

From your link:

  To be vulnerable, a web application must:

  Be served from a server that uses HTTP-level compression
  Reflect    user-input in HTTP response bodies
  Reflect a secret (such as a CSRF    token) in HTTP response bodies

However, if your resources are static and are the only items compressed then:

Be served from a server that uses HTTP-level compression
Reflect
user-input in HTTP response bodies
Reflect a secret (such as a CSRF
token) in HTTP response bodies

For your non-compressed dynamic items:

Be served from a server that uses HTTP-level compression
Reflect
user-input in HTTP response bodies
Reflect a secret (such as a CSRF
token) in HTTP response bodies

Key:

Applicable to your situation
Not applicable

As no one request satisfies all three requirements, you are not vulnerable to BREACH.


How can I stop this attack on my router? After enabling system log on my Asus DSL-N10E router, I've got this message:

  DoS: Tcp SYN With Data Attack source=217.74.166.73

What does it mean? Is it a real danger on my network security? And how can I protect my network from these attacks?

This is very likely not a Denial of Service attack. As a matter of fact, this looks very much like a SYN Port Scan. Someone (very likely automated, by an infected machine) is attempting to scan your machine. They send a SYN packet to you on a certain port, then your machine responds with an ACK packet.

There's no real danger here. This is the Internet; someone will always try to scan your machine and try to infect you. Outside of books and in real life, nobody really is going to DoS your home router. Your router is already doing a good job by detecting and DROPing those packets.

My advice: Forget about this, and move on with your life.


Is this a secure data exchange scheme for a game? I am writing a multiplayer game. I have a central server which processes everything. For data exchange I use HTTPS protocol. Because this is a game I cannot use computationally expensive systems like RSA for data transfer.

To login,

Client uses sha512 to produce hexadecimal hash from password and random seed.
Client sends "login" request with username, hash and seed to the server.
Server checks if user has not attempted too many login requests and checks whether the password hash matches the hash made from the password in the database. If it does, it sends an access_key and a response that login was successful

To send requests which require login,

Client sends a hash generated from the access_key and seed along with the request data.
Server checks whether the IP has not changed and whether the hash made from access_key and seed is correct. If it is, new access_key is generated from the old one, request data is processed and the server returns the new access_key along with the response from the request.

At any time, if client's IP changes or invalid access_key is sent, the session is automatically terminated.

How secure is this approach? What can I do to improve it?

First of, crypto is hard, and you shouldn't create your own.

Vulnerabilities

Your login seems to suffer from a pass the hash vulnerability. An attacker doesn't need to crack the hash to login, they can just pass the hash, and will be logged in. This defeats the purpose of hashing the password in the first place.

sha512 is not recommended for storing passwords, as it's way too fast. Use something like bcrypt instead.

HTTPS and Encryption

You say that RSA is too expensive. But generally, RSA is only used to exchange a key, which is then used with a much less expensive private key cryptosystem.

As you clarified that you do use HTTPS, it should be noted that you do already use RSA. HTTPS uses RSA or diffie hellman for key exchange and some block or stream cipher for the actual data encryption.

As you use HTTPS, you already have data confidentiality and integrity (and server authentication and optionally client authentication), there is no need for additional encryption on the application level.

Advantages of your scheme?

Your scheme doesn't really seem to serve any purpose. You already are secure from eavesdropping and data tampering via HTTPS (and your scheme wouldn't have prevented it anyways).

So your scheme doesn't seem to be about data exchange so much, as it is about authentication.

Generally, authentication is handled like this:

Login:

Client sends username and password (plain)
Server hashes password, and compares hash against hash in db
Server sends session id back

Other Requests:

Client sends session id
Server validates session id
(optional) when session state changes, server regenerates session id

Your approach is similar, but did introduce the pass the hash vulnerability, and contains a seed, which seems to be unnecessary and thus only complicates the scheme. It also regenerates the session id on each request, which isn't really needed and only seems to cause unnecessary overhead.


Is GPG suitable as part of a password manager and generator? I assume that GPG is very strong to crack, guess, etc. Since I have confidence in GPG, would it be appropriate to use my GPG key as the master key for a password manager or generator?

GPG encrypts your data with a symmetric key, then encrypts  that symmetric key with / for the public / private keypair. That keypair is usually kept safe by symmetrically encrypting it.

What you're asking for is a program that would diagram as such:

Symmetric -> Asymmetric -> Symmetric

What you should use is a password manager that does the following step:

Symmetric

The job of a password manager is as much one of not placing your data in cleartext as it is simplicity. GPG's job is to allow communication of a key exchange across a clear channel. Since you'll be the only one encrypting / decrypting your passwords, symmetric encryption is just fine. Cryptographically speaking. GPG uses OpenSSL for the backend anyway as a great number of freely available password managers most likely do.

Now, with all that said, it makes good sense to do this on your computer if your GnuPG key is held on an external smartcard, and it'd work with a phone if there were an NFC version of the card. You could use git for synching various password files.


What does ENV (“_”) do for anti-debugging? I'm reading some PPT and it says ENV("_") can be used for anti-debugging in Linux

Does anyone know what it means?

Bash sets the environment variable _ to the path to the command that is being executed. So do zsh and pdksh. But other shells, such as fish and dash (which is the default scripting shell on many Linux distributions) don't do it. ATT ksh sets it to a value which includes the path to the command.

The idea is that a program can check the value of the environment variable _ to see what invoked it, I guess. Except that this is extremely unreliable even if the user isn't doing anything to change it. If the program is launched from a GUI or via a script, _ could be empty or could have some completely unrelated value, and that's perfectly legitimate and very common. And of course if the user does want to change it, it's absolutely trivial — just run env -u _ myprogram or env myprogram.

As “anti-debugging” measures go, this one is pretty ridiculous. Not only is it spoofable with zero effort, it wouldn't actually work in normal use. If some reading material touts it as an anti-debugging measure, I would recommend against this material as very unreliable.


Does calling with wireless phone have enough security? I'd like to know if calling with a wireless phone at home can be heard by neighbours and if it is safe.

It depends on what you mean by "wireless phone at home":

GSM phone - then yes, all transmission between your phone and GSM station is encrypted
DECT phone - then partially: all wireless transmission between the phone and its base station is encrypted, however neighbours can plug into your analogue, unencrypted phone cable
cheap no-name wireless phone - it depends on what technology have been used, but still your neighbours can plug to your analogue, unencrypted phone cable

You can avoid plugging to an analogue phone cable by using ISDN phone (where available), or VoiP.


How does the MFT encryption work? A few week ago there was a ransomware called Petya delivered via Dropbox links. The new ransomware is inserted into the master boot record (MBR) of the victim's computer, and the system restarts. On reboot, the hard disk will be encrypted. The solution is described here :

  Computer experts from the popular tech support forum BleepingComputer.com confirmed that the technique works, but it requires extracting some data from an affected hard drive: 512 bytes starting at sector 55 (0x37h) with an offset of 0 and an 8-byte nonce from sector 54 (0x36) offset 33 (0x21).

How does the Master File Table encryption/decryption work (For non-expert users)?

This article at malwarebytes is very informative.

The ransomware uses a small kernel with a built in crypto engine, and when it pretends to run chkdsk it actually encrypts the MFT using a key generated for that machine and sent to the attacker.

The same engine will run the decrypt based on a key given when you pay the attacker.

As the MFT is the reference for every block of every file, without it you can still see all the data if you analyse the drive, but you don't know how it fits together, what block is part of what file etc.

The Salsa20 algorithm works like this:

uint8_t *key = 128_bit_key_generation();
uint8_t *nonce = unique_message_number();
unsigned len = 500;
uint8_t buf[len];

// Position (in bytes) in the stream
uint32_t sindex = 0;

for (sindex = 0; sindex < 5000; sindex += len) {
    // recv 'len' bytes into 'buf'
    s20_crypt(key, S20_KEYLEN_128, nonce, sindex, buf, len);
    // copy 'len' bytes from 'buf' elsewhere
}


What is Virtual Machine Introspection? I have seen it  presented as a special security technique but it seems like it basically means automated security monitoring of your virtual environment. Is that the basic idea?

As the article describes it, VM introspection looks like inspecting the contents of the VM in real-time, to see that everything appears to be "in order". Virtual machines allow for such inspection without consent or knowledge of the guest system. This contrasts with classic antimalware software on physical systems: the antimalware runs on the system itself, so it is reachable by successful malware; indeed, when some virus or malware succeeds in taking control of a given machine, its first task is to deactivate any antimalware software on the machine, and prevent installation of such software, so that the malware can keep on controlling the machine.

Thus, classic antimalware software must reliably block malware upon entry; if they miss one, they have lost. On the other hand, with a VM, the antimalware could run on the host, outside of the guest, thus impossible to deactivate by malware who subverted the guest system. That's the VM introspection concept. It may possibly "clean up" an infected machine.

It is like surgery. Self-surgery is, let's say, difficult. In particular, invalidating illnesses may make you unconscious, thus unable to heal yourself. An external doctor, being healthy at that time, is still able to help you.


iPhone Tracking debacle - risks and countermeasures For those of you who are not familiar with the topic, a quick search will turn up a lot of hits, e.g. see the researcher's report at Got an iPhone or 3G iPad? Apple is recording your moves - O'Reilly Radar and their application at petewarden/iPhoneTracker @ GitHub, and Fox News: Apple iPhones Track Your Location, British Experts Warn
To summarize, there was a recent "discovery" that iPhones track your location via cell tower tracking, and store months of that data in a single file, "consolidated.db". Thus, a hardcopy record of your phone's every movement (while the phone is on).  The data is typically also backed up by iTunes to your computer.

See e.g. Marco Ramilli's Blog: iPhone Tracker  (thanks @atdre for the link) on the one hand, or 3 Major Issues with the Latest iPhone Tracking “Discovery” | Alex Levinson (which notes the similar predecessor file, h-cells.plist) on the other.

My two part questions here, without speculating on what is actually done with that data (unless you have hard information):

What is the extent of risk here? What is the worst impact, and what does this mean? Basically I'm looking for a threat model / risk profile on this data.
(Assuming the risk is high enough... )  How can one go about protecting themselves (short of dropping the iPhone altogether)? e.g. protecting that file, preventing the logging, deleting it, setting it to not send, etc.

Note that privacy exposures of location tracking information for other phones is also on-topic here.

I dunno, the following seems like an easy way to get information on someone, without much work at all.

From http://www.wired.com/gadgets/wireless/magazine/17-02/lp_guineapig?currentPage=all

  To test whether I was being paranoid, I ran a little experiment. On a sunny Saturday, I spotted a woman in Golden Gate Park taking a photo with a 3G iPhone. Because iPhones embed geodata into photos that users upload to Flickr or Picasa, iPhone shots can be automatically placed on a map. At home I searched the Flickr map, and score—a shot from today. I clicked through to the user's photostream and determined it was the woman I had seen earlier. After adjusting the settings so that only her shots appeared on the map, I saw a cluster of images in one location. Clicking on them revealed photos of an apartment interior—a bedroom, a kitchen, a filthy living room. Now I know where she lives.


Is there readily available encryption algorithms for current computers, that is safe from quantum computers? Is there readily available encryption algorithms for current computers, that is safe from quantum computers? I know a bunch of currently popular encryption algorithms that are safe from current computers, but significantly weaker against a quantum computer. For example, Shor's algorithm to break RSA.

What algorithms can I use on my computer/phone today if I want my data to be secure 50-100 years from now, when (hopefully) quantum computers are basically commodity hardware? Partially ignoring the fact that we might get a break-through in cracking these algorithms 20 years from now. I'm sure there's been quite a lot of research into encryption algorithms for quantum computers. Having to implement the algorithm myself is not that much of a problem, as long as it's feasible to use for file or disk encryption on current hardware.

EDIT:

I am aware of this question: What kinds of encryption are not breakable via Quantum Computers?, but since it's been two years since that question and answer, I'm wondering if there's anything new.

The answers to the linked question give a very good overview of why quantum computers break modern encryption schemes (RSA and Elliptic Curve Cryptography (ECC)), but not how to mitigate against it.

Summary: expect it to take until ~2020 to work the kinks out of post-quantum algorithms - Use AES-256 for now!

As mentioned in Thomas Pornin's answer to the linked question, AES-256 gets a gold star for being quantum resistant. So, for the time being the best thing you can do is to encrypt your data with AES-256 and be really really careful with the key (keep it on a separate drive from the data, stored in a separate location, etc).

My personal opinion is that there's going to be a bit of a gap between when people stop trusting RSA and ECC and start trusting post-quantum encryption for long-term data storage. During that gap I suspect we're going to go back to physically mailing AES keys in tamper-proof envelopes.

I attended the recent PQCrypto2016 conference in February 2016, during which it was clear that this work is still in its infancy with a lot of basic mathematical research still to be done on post-quantum encryption. Post-quantum signatures are much more mature, but since your question is about encryption, I'll stick to that. At the conference, professor Steven Galbraith said that virtually every week a new weakness is found in one of the leading schemes, and a new variant is proposed to address this. So we want to give the mathematicians a few more years before we write any software that we trust.

The holy grail is to find a quantum-resistant encryption scheme that is a drop-in replacement for RSA, ECC, and the Diffie-Hellman key exchange. The problem with the current slew of proposed algorithms is that they are either very slow or have very large keys, very large cipher texts, or all three! (By "very large keys" I mean 4 - 10 megabytes, compared to a 2048 or 3072 bit RSA key, or a 233 or 283 bit ECC key).

NIST Competition

At the conference, NIST announced a competition for post-quantum crypto algorithms that will lead to new standards. Submissions were accepted Jan-Nov 2017, resulting in 60-70 entries.

These submissions from NIST must be accompanied by sample code in C, and must waive any patent or usage rights, so I imagine some of the open-source crypto libraries will start incorporating them pretty quickly as "experimental". At that point you should be able to protect your data with a quantum-safe algorithm - and don't worry, quantum computers aren't nearly mature enough for the NSA to have one, so your RSA-protected data is just fine for the time being.

That said, this probably won't quite satisfy your

  I want my data to be secure 50-100 years from now

since these algorithms will go through rapid evolution as new weaknesses are found, and optimizations are invented, so data you encrypt with an experimental algorithm in 2018 will probably not be decryptable by whatever variant we end up standardizing at the end of all this research.

OpenSSL and Bouncy Castle today

According to the cipher lists for OpenSSL and Bouncy Castle, neither of them currently support any quantum-resistant ciphers. Bouncy Castle tends to be pretty quick to implement new things, so we may see them try some of the experimental algorithms from the NIST competition within the next 12 months.


What is the most secure way to send emails using PGP? I am a PGP beginner, having just downloaded GPG for OS X. I created my first pub/sec key for my email address and uploaded it to the public key server.

GPG has several features available, namely: 1) encrypt, 2) decrypt, 3) sign, and 4) verify. Given these options: What is the most secure way to use PGP to send & receive emails?

When sending, do I encrypt my emails? Or sign and encrypt? Or just sign? Which is best? And what is the difference between them?

What about receiving emails? What do you consider the most secure? If someone sends me an email, should I insist that it be signed? or encrypted? or something else?

There are many, conflicting explanations on blogs, tutorials, etc. for the best way to use PGP. I am looking for a "Plain English" explanation, geared towards non-InfoSec people like myself.

Note: I am not using the OS X Mail app, as I use a 3rd party email client (Sparrow).

Update: I am not interested in installing another email client. GPG comes with OS X Services menu items including encrypt, decrypt, sign, and verify. These will work with any application, email or otherwise. That is what I am using.

The most secure way to send and receive emails via PGP is to sign and encrypt them.

Signing provides integrity, allowing recipients to verify that the message was sent by you and has not been tampered with.

Encryption provides confidentiality, ensuring that any person who intercepts the message will not be able to read it.

Both of these are important aspects of security, although in some cases you may decide you only need one and not the other when sending mail.

For receiving mail, the one you are most interested in is signing, otherwise you cannot guarantee that the message is indeed from the sender. If you receive an unencrypted message, other people who are/were able to obtain it would be able to read it, but there's not much you do about that if its already been sent (unless you wanted to encrypt it for storage on your own PC, or to forward on to other people).


How could a server to server rest api communication be more secure, by using OAuth 2? I created a large backend+frontend project for a client. They recently started a different project, and contracted an other company to develop and host it. Since they need some of the data from my project, they asked me to develop an api, so they can access the required data.
I created a rest api, where the client is authenticated with an api key. This api key is sent in each api request in a http header, named X-MY-AUTH-CODE. Since the api is only available over https, as far as I know an attacker is not able to eavesdrop the communication, and access the api key.
Some folks recommended me to use OAuth 2 for this task, but I don't understand, what would I benefit from it:

The users don't have to consent to anything
It is purely a server to server communication
The OpenApi tokens are also sent in an Authorization: Bearer http header, which as I see is just as secure as sending api keys

How could a server to server rest api communication be more secure or straightforward, by using OAuth 2?

There can be multiple reasons for this depending on how the services are generally deployed in the organization/system and what is the typical authentication mechanism. It would be weird to use a different authentication mechanism just for one service.
If one had to make a blanket statement, then I think the advantage is in terms of token expiration. The API keys have no expiration date while the OAuth tokens generally do. This way, even if some rogue server in your system was able to grab your OAuth token, there will be a limited amount of time till they are able to authenticate.


Determine if private key belongs to certificate? Given a certificate¹ and a private key file², how can I determine if the public key on the certificate matches the private key?

My initial thought was to simply encrypt some text with the public key on the cert, and attempt to decrypt it with the private key. If it roundtrips, we've got a winner. I just can't figure out how to do this with OpenSSL.

Alternatively, if I could generate the public key from the private key, I could just compare their fingerprints. SSH seems to have a command for this (ssh-keygen -y -f my_key > my_key.pub), but the hashes don't match. (I'm nearly certain I have the key corresponding to the cert, as the webserver is serving with it, but I'd like an easier way that spinning up a server to check.)

¹ a .crt file, in x509 format, I think. OpenSSL can read it with openssl x509 -text -in that_cert.crt

² An RSA private key

I'm going to assume you have ssl.crt and ssl.key in your current directory.

If you want to see what's in your certificate it's

# openssl x509 -in ssl.crt -text -noout

Two of the things in here will be the RSA public Key's Modulus and Exponent (in hex).

If you want to see what's in your private key it's

# openssl rsa -in ssl.key -text -noout

Note the public key is usually in there (at the very least the modulus is required to be in there for the private key to work, and the public exponent is usually 65537 or 3).  So you can simply check if the modulus and public exponent match.  Granted, if you want to check that the private key is actually valid (that is d and e are valid RSA exponents for the modulus m), you would need to run

# openssl rsa -check -in ssl.key -noout

EDIT (2018): Please note if you are checking that a private key coming from an untrusted source corresponds with a certificate, you MUST CHECK that the private key is valid.  See here for an example where not checking the validity of a "leaked" private key lead to a CA improperly revoking a certificate.  You may skip this step if you know you validly generated the keypair.

Now you can simply generate the public key from both the certificate and the private key and then use diff to check that they don't differ:

# openssl x509 -in ssl.crt -pubkey -noout > from_crt.pub
# openssl rsa -in ssl.key -pubout > from_key.pub
# diff from_crt.pub from_key.pub

Or as a one liner that doesn't create files (using process substitution):

# diff  <(openssl x509 -in ssl.crt -pubkey -noout) <(openssl rsa -in ssl.key -pubout)

If the keys match, diff shouldn't return anything.  (You probably will see "writing RSA key" output to stderr from the second command).

Note  your webserver probably would loudly complain if the certificate and private key didn't match.  E.g., with nginx using the wrong key (same size, same public exponent, but last year's key) for the certificate nginx is using:

# sudo /etc/init.d/nginx restart
* Restarting nginx nginx
nginx: [emerg] SSL_CTX_use_PrivateKey_file("/etc/nginx/ssl/private/wrong_key.key") failed
(SSL: error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch)
nginx: configuration file /etc/nginx/nginx.conf test failed


Why there is a signed hash in Certificate request (.csr file)? I wonder why there is a hash signed by private key in the CSR? It does prove that I have the private key that belongs to the public key in the .csr. But who cares whether I  actually do possess the private key? The CA doesn´t need this proof for signing the CSR. It just signs the "Subject" data, some metadata and the public key.

Could you pls describe an Attack that would be possible if there was no signed hash in the CSR request?

Thank you

From the RFC, note 2:

  Note 2 - The signature on the certification request prevents an
     entity from requesting a certificate with another party's public key.
     Such an attack would give the entity the minor ability to pretend to
     be the originator of any message signed by the other party.  This
     attack is significant only if the entity does not know the message
     being signed and the signed part of the message does not identify the
     signer.  The entity would still not be able to decrypt messages
     intended for the other party, of course.


How is it possible to do TLS through proxy without anyone noticing? My workplace uses a proxy to connect to the internet, even for https sites.

It was my understanding that for this to work, the proxy would be considered a MITM, and the certificate presented would be from the proxy.

This root for this certificate would need to be trusted, which would be easy to achieve via group policy in a corporate environment.

However, this is not what I'm seeing.

I'm seeing the genuine cert chains from the target website, but wireshark is showing that I only ever hit my proxy.

What gives?

Normally, when HTTPS is done through a proxy, this is done with the CONNECT mechanism: the client talks to the proxy and asks it to provide a bidirectional tunnel for bytes with the target system. In that case, the certificate that the client sees is really from the server, not from the proxy. In that situation, the proxy is kept on the outside of the SSL/TLS session -- it can see that some SSL/TLS is taking place, but it has no access to the encryption keys.

Some organizations implement a full Man-in-the-Middle by generating a fake certificate for the target server on the fly. They do so precisely so that the proxy can see the cleartext data and scan it to conformance to the organization policy (e.g. automatic antivirus scanning). This can work only if the client (your browser) accepts the fake certificate as genuine, which in turn requires that a special organization-controlled root CA is pushed on the client machine (and in a Windows / Active Directory world, a GPO can do that).

About all major vendors for firewall/proxy appliances offer that mechanism as an option.

Not all organizations deploy such a MitM system, for several reasons, including:

Automatic MitM can be expensive. The proxy appliance may have to be computationally powerful if there are many users; and the product license can be high.
MitM breaks certificate-based client authentication.
Doing a MitM makes sense only if you actually inspect the data, which again increases the computational costs.
The automatic pushing of a root CA does not work with BYOD.
As a rule, users really dislike such MitM.


Questions about RSA/asymmetric key encryption? I've been reading a lot about quantum computers and RSA. I know RSA security relies on the difficulty of factoring an extremely large number with just two prime factors. Apparently quantum computers claim to be able to factor them within minutes. I wanted to know about some viable alternatives to RSA, possibly something more recently developed.

Another question I have is, if an encryption key is public that can be used to send a message to a server, how can I prevent someone from encrypting a message (for example, a hypothetical delete everything message) and sending it to the server if they sabotaged Internet lines? Is there a way to prevent this?

You're looking for two things, both of which RSA can provide:

You want to encrypt a message so it cannot be read without the private key of the destination.

This is encryption TO the public key of the destination.  You're doing this already!

You want the destination to be able to verify that you, the approved source, is in fact the one who sent the message.

This is signing and verifying.  You need to sign the message with your (the source's) private key when you're encrypting it to the destination's public key.  Then the destination uses your (the source's) public key to verify who sent the message.

An example of using GPG to do this from a batch file (i.e. automated commands - you SHOULD have an RSA key pair for nothing but this, since the passphrase is vulnerable in the batch file).  If you have a human sending commands, they should NOT use the --passphrase argument; have them enter it into your software so it's not vulnerable!

  gpg --batch --encrypt --sign --local-user "Your own private key <YourEmail@you.com>" --passphrase "Put your private key passphrase here" --recipient "DestinationKey <their email>" --output "test.command.gpg" "test.command"

You will, of course, need to make sure the destination verified the message, and that the signing key is, in fact, the correct one.

Another reference is What is the difference between encrypting and signing in asymmetric encryption?.

EDITED TO ADD: As far as alternatives to RSA for asymmetric encryption, the two most common that I'm aware of are DSA (based on discrete logarithms, and please try to use a |p| >= 2048 and a |q| >= 224, just as you'd use at least 2048 bits for your RSA key) and EC (Elliptic Curve - be very careful which curve you pick - the 25519 curves seem to be well regarded so far, ans use at least 256 bits) variants like ECDSA (Elliptic Curve Digital Signature Algorithm. See Signatures: RSA compared to ECDSA and RSA vs. DSA for SSH authentication keys for references.


Denial of Service by SQL queries - are selective queries better than queries that return a lot? Lets say I have a search form for a blog (or any other system that would use SQL to run queries) and I want to protect it from denial of service. An attacker wants to attack my site by flooding the search function, which would cause a lot of SQL queries and might result in DoS.

This is theoretical so it's not about a single type of language or database management system, but if you want to you can imagine it's PHP and MySQL (although I'm wondering about the effects in general rather than specific to one platform).

A request like GET /search.php?s=[SEARCH] searches the database for all articles containing [SEARCH] and returns them. Let's say the maximum character length for [SEARCH] is 128.

I am wondering in terms of "performance loss" which would be the worst form of attack between these two scenarios:

The attacker searches for a random string of 128 characters (ex. aisoizeuf[...]deuedujed).
The attacker searches for a single character each time (ex. e).

At first I thought that attack #1 would be more effective, thus legitimizing a strict limit on the character length of the search query. But then I thought, since in my example we're talking about a blog, that multiple searches on a single character might return a lot more articles because almost anything you write will contain at least one vowel. So then I realized perhaps it's not such a clear cut answer.

Attack #1 will require more ressources to send the query and scan all the entries in the database, but it won't return anything, whereas attack #2 will do the opposite - it won't take up a lot of ressources to scan the database but since almost every entry will contain an occurrence of the search query, it will return almost every entry in the database

Which attack do you think will be more dangerous and use up more ressources?

You can mitigate both of these issues by creating a FULLTEXT index. In other words, instead of having the database system read the entire table and scan every character in every field, the system builds an index that can be quickly searched while discarding common words/letters. Your attacker can search for "e" as fast as they want, and the index will answer with no results returned in a matter of a very small fraction of a second (and with appropriate caching, future searches will cost even less). This can reduce the amount of searching needed from millions of bytes to just a few hundred bytes, which is a trivial operation for a computer.

Most FULLTEXT indexes tend to use a "b-tree" (or, binary tree) implementation. This means that even if your attacker sends 128 random characters, as opposed to just one character, the database only needs to go until it can prove that there's no matching values, which means it will not search all 128 characters, assuming we're talking about actual random values. The most exhaustive search that the attacker could perform would be to actually use real words from a dictionary that are also in your blog. You could also restrict searches to a minimum length by discarding words less than, for example, three characters long. This would make your index more effective and reduce the capabilities to spam small searches.

As far as "dangerous" goes, it's unlikely that either attack would cost very much in terms of cost assuming it were a personal blog-- the entire database can fit in memory and thus wouldn't contribute very much to server load even if it were being hit hundreds of times per second. You'd be more likely that a DDoS would occur simply because your server's OS can't handle any more pending connections rather than the limitation of the database itself. Most databases can handle hundreds of simple index queries per second, even on a home computer.


Security principle regarding softwares Security through obscurity isn't real security.  That's why
  theoretically, closed source software is a wrong solution. A
  software, example an operating system still needs to be secure when
  all of it's elements are known to source code level, only the private
  keys are kept secret.

Q: Who are the people (that work in security, cryptography) who said these words? The more examples for people are there the better.

This question will be useful in future arguments when people need to discuss open vs. closed source software models regarding security.

"Security by Obscurity" is among the most commonly used (sometimes misused) phrase in security industry. The phrase is supported by giving examples like, leaving the back door of your house open, as nobody knows about it or like keeping the key of your house under the door mat or in a flower pot next to the door.

As per wikipedia, the origin of the phrase can be traced back to the Kerckhoff's principle, "a system should be secure because of its design, not because the design is unknown to an adversary".

One such example I can remember is encryption and authentication process in Whatsapp messenger (though in case of encryption, it could be a case of ill-informed cryptographic implementation, but considering it is a well funded company and still lacking on such important aspect, makes me think on lines of "security by obscurity" as well).

As per wikipedia, NIST in its document on "Guide to General Server Security" talks of this security principle. Bruce Schneier in this article talks about it as well. There are many other references on wikipedia like, Peter Swire, Jay Beale etc.

This brings to the important part of the question, does it prove that open source is better than closed source. In my view, it depends on the size of the project, how many developers are working, background of developers, and quality control practiced. There is no way to tell which one is more secure than the other one, just by looking at the model of development used. Historically, both the camps have chequered history.


Safely running malware without a VM I want to run untrusted software in a way that can only destroy files belonging to that software.

I believe such is common on GNU/Linux, e.g. running Apache as user "www" that only has read access for its data and read/write access for its temp files.

How do i achieve the same on Windows?

Depends on the malware you have "developed", the real answer is simply NO.
I've seen malware starting with guest user rights and escalating to Admin.

If you need an alternative solution to a VM in order to run Malware on your pc with full PC controls and no consequences is DeepFreeze.

Once installed, you can run anything or delete anything on your PC. It will always boot back up normal, same as the moment you installed DeepFreeze. Disable it and all the changes are written permanently. If enabled it will always boot back in normal state no matter what you do, even if you delete /system32.. :)


Two factor authentication: Why ask for password first? Every website that I came across  that uses two-factor authentication asks the user for their password first. Then, after a correct password was entered, an SMS or an e-mail is sent that contains another code you have to enter in order to actually get logged in.

I wonder why that is the prevalent scheme, since I could come up with mechanisms that seem to be much secure to me:

Asking for an external authentication first.

(Pro) The attacker cannot try different passwords first. This seems especially advantageous if the user reuses their passwords.
(Con) The user could be spammed this access codes.
The con could be easily fixed by using a cool down between requests.

Only sending a code if the password was right, not telling if the password was right or not.

(Pro) The attacker cannot know if the entered password was right or wrong.
(Con) A user may be annoyed the they don't receive their code, since they don't see directly if the entered password was right.
That con could be fixed by sending the user a message that a wrong password was entered, or only truthfully telling the user/attacker 3 times if the entered password was wrong, and say it's right afterwards for any password.

If your model suggests doing so without the username also;

You can't do this because not all 2FA tokens are the same. Each token is unique (secret key) and therefore you must identify the individual attempting to login before you know which token you are dealing with to check against it.

In the manner you suggest submitting any token code will immediately validate to an unknown user whose token happened to be valid at that time, or no one, which in large websites with many hundreds of thousand of users increases the likelihood of hitting the correct code for any one of those users. Especially since modern 2FA usually employs some kind of window allowing codes to remain valid before and after the current correct iteration (accounting for clock skew and other time difference sources). So each user could likely have many valid codes available at a time, further increasing the chances of success.

I'm not sure you would be able to withhold the information from the user if they typed the wrong password either. I agree you don't send a code (in the case of sms or email codes), but if the user does not understand that the site had a problem, and what that problem is, it creates a frustrating experience for them (as you pointed out in your cons of part 2). Companies hate frustrated customers a lot more than they hate lower security.

Lastly, this would create a way for attackers to run spam that comes from a legitimate business in the case of SMS and email codes. Clicking the send my code button for all codes ever, even with cool-down will get annoying if it keeps appearing every cool-down.

If however in your model you suggest that the username is required;

If username and then the code is required, and a cool-down period is applied to prevent attacks, I would still advise against it. In that case, by only knowing the username, I can run a DOS on that user, forever, with little to no effort. Simply specify username and keep submitting codes. The lower you make the cool-down, the better it is for the user, and attacker, brute-forcing essentially a 6 or 8 digit all integer password. The longer the cool-down, the worse for the user, and better for attacker doing a DOS. In both cases the user loses, attacker wins.

To sum it all up the reasons I think the internet gravitated toward this system are as such:

Username/Password systems were already in place at the time and hardware 2FA were the first ones to arrive, meaning it was absolutely required to know who the user was first.
2FA implementations, even ones in software (the kind to send to email and SMS) are often the same methodologically as the hardware keyfobs. Thus have the same identification requirement.
Servers are good at dealing with a flood of requests in the case of attacks, end-users are not.
It is simpler to verify someone's identity with their predefined credentials directly with the server first rather than rely on a multitude of systems which you are not certain are currently up (server01 > sms service > GSM > air > Tower > iPhone > User > internet > ... > server01).


How should I audit and monitor shared TCP ports in Windows? Windows has a feature called .NET TCP Port Sharing which allows different .NET applications to share the same TCP/IP port.

I would like to monitor the source and destination connections of each client and associate them to the relevant server side listener.  How do I reliably & efficiently accomplish this?

I think the only real audit you can do here is to actually turn the service off. Besides that I think the only limit you can set are the authorized security identifiers (SIDs) which can be configured (as described here on msdn).


2FA with Windows NPS I would like to set up two-factor authentication for my Wireless users.

I have an Windows NPS server that is currently authenticating my wireless users and I want to add certificates or any other second factor for authentication.

Microsoft NPS supports certificates, but I don't see the way to force users to authenticate using username/password AND certificate.

It can only be either or. I.e. I can configure the server to use certificate OR username/password authentication.

Is there any way to force 2 methods?

Or may be there is some other free/cheap way to configure 2FA for wireless users. I believe it's possible to use freeradius with Google authentication, but where will users enter OTP in this situation?

Thanks, Roman

Roman,

The problem is that Google authenticator is only one factor.   You would need to change the login process for your access point to handle two steps and that's usually quite hard.  You can use a system like RSA that pin-appends and then strips it out or like ours that requires the pin before you get the OTP.

Note that NPS does not use the AD password for authorization. So using a pin as the what you know is all you need.

See this doc for a working example: https://www.wikidsystems.com/support/how-to/how-to-configure-nps-2012-for-two-factor-authentication/.

Hth,

Nick


How to fix the audit failure in our web server We noticed that we are getting the following audit failure logs in our web server. The workstation is not in our network.

Can anybody help me how to isolate and prevent this from happening?

An account failed to log on.

Subject:

Security ID:        NULL SID
Account Name:       -
Account Domain:     -
Logon ID:       0x0

Logon Type:         3

Account For Which Logon Failed:

Security ID:        NULL SID
Account Name:       db2admin
Account Domain:     SAYNAMY-4BF9DFF

Failure Information:

Failure Reason:     Unknown user name or bad password.
Status:         0xc000006d
Sub Status:     0xc0000064

Process Information:

Caller Process ID:  0x0
Caller Process Name:    -

Network Information:

Workstation Name:   SAYNAMY-4BF9DFF
Source Network Address: 37.220.1.6
Source Port:        1046

Detailed Authentication Information:

Logon Process:      NtLmSsp
Authentication Package: NTLM
Transited Services: -
Package Name (NTLM only):   -
Key Length:     0

It looks like you may be victim of either a targetted attack or a simple script kiddie attack. Basicly someone (SAYNAMY - 37.220.1.6) is trying to authenticate with known DB2 administrator username to your server. A RIPE search excerpt follows:

inetnum:        37.220.1.0 - 37.220.1.63
netname:        RSDEDI-OJEJMBME
descr:          Dedicated Server Hosting
country:        GB
remarks:        ABUSE REPORTS: abuse@redstation.com

Important questions:

Are you running DB2 on the affected server?
Can you track other requests from that IP into your network by looking at e.g. firewall logs?

If you want to FIX this issue I would simply block this IP address in the firewall and the audit failure from this IP should not arrive anymore.

To block the IP address on the servers own interface you can use windows command line like this:

netsh advfirewall firewall add rule name=[NAME HERE] dir=out interface=any
action=block remoteip=[IP HERE]/32


Web App encrypting data on client with login password? I'm writing a web app for Personal Information Management that runs in the Cloud. For that I'm considering client-side encryption using AES256 with window.crypto and SJCL as fall-back for older browsers. The encryption would then be based on the user's login password. In addition, I'm also thinking of doing the password hashing on the client side.

Is that actually increasing user privacy? Or am I missing anything? I know the standard way is to just store data "plain text" and do server side hashing.

EDIT To add a clearer scope, the intention is: in case the database gets stolen, the user data should be difficult to read. (At least it won't be plain data in that case.) At the same time, when user foo@gmail.com's uses 123456 for his mail account and for his WebApp PIM account, an attacker still has to reverse the password hash in order to access foo's Gmail.com.

In particular imagine the following scenario: an attacker can get the database and checks user foo@gmail.com's database records. He gets the hash, and some encrypted user data. With the hash he can login to WebApp PIM's API. However he can not read the user's data.

With the leaked hash, the attacker could easily compromise the data through the API, but that doesn't matter so much for this scenario. The primary goal is to increase privacy of the user data in case of a database leak.

(In addition I would like to allow the user to at least slightly distrust the WebApp hoster reading private data. I'm sure this solution doesn't get close to that, but at least it could be a first step.)

Regarding performance: the Web Crypto API can do PBKDF2 which seems fine to me for hashing. (Github Example) SJCL might be too slow as fallback, so it might make sense to transpile C++ to (asm.)js.

Please see this and this questions and all of the answers about client side hashing/encyption.

To sum it up, browser JavaScript is too slow for password hashing function like bcypt or scrypt which you will want to use to derive a key for AES from user password. You will need to reduce number of iterations and/or other hash parameters and thus reduce overall security of the implementation. If you want client side hashing/encyption, you will need to create browser extensions much like popular online password managers do.

EDIT:

If you or user distrusts WebApp hoster reading private data how can you trust WebApp hoster to deliver trustworthy code? What is to stop WebApp hoster injecting JavaScript code that will leak information before encryption?

To elaborate more directly about problems with browser cryptography please see these links:
https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/

https://tonyarcieri.com/whats-wrong-with-webcrypto

For a more recent opinion:

https://www.cossacklabs.com/whats-wrong-with-web-crypto.html

Regarding user privacy, you will not store plain text. You can use SSL to transmit plaintext and store it encrypted using a key derived from user password. Store hashed password for authentification. Do all encryption and hashing server side. Either that or deliver native application/web browser extension which can be signed and verified. In that case you don't have to trust WebApp hoster, you will just use it for (encrypted) data storage.


PCI-DSS - one application per server? How do I interpret the 2.2.1 point for PCI-DSS? Is "application server" 'one primary function' or does it need to be "program x server", "program y server" etc?
I have a collection of applications that run server side within my environment. Some of these  interact indirectly with the application that the cardholder data resides in, others not. These applications also have varying groups roles, and permissions assigned within them and serve different departments.

2.2.1 Implement only one primary  function per server to prevent functions  that require different security levels  from co-existing on
the same server.  (For example, web servers, database servers, and DNS
should be implemented on separate servers.)
For example:
A database, which needs to have strong security measures in place, would be at risk sharing a server with a web application, which needs to be open and directly face the Internet.
Failure to apply a patch to a seemingly minor function could result in a compromise that
impacts other, more important functions (such as a database) on the same server.
This requirement is meant for all servers within the cardholder data environment (usually Unix, Linux, or Windows based). This requirement may not apply to systems which have the  ability to natively implement security levels on a single server (e.g. mainframe).

So basically what the requirement is saying is that you need to assign one primary function per server.

The server you've described sounds like it runs a few applications for production users to utilize. This would be classified as an "application" server. However, you've also mentioned that there are multiple applications on that server, some touch the CDE indirectly and others do not. While this server would be considered to have one primary role, it brings the controls of the applications that don't touch the CDE into consideration.

If it were me, I would move the applications that don't interact with the CDE off of that box and move them to a different server, in a different segment if possible. If you don't have a segmented network (which you should really, really do) then everything is in scope anyway, so this advice doesn't matter.