Many different types of hardware write-blockers (e.g., wiebetech brand) will identify the HPA and DCO and remove them for you if you choose. Once the HPA and DCO are gone then wiping the disk, e.g., with dd, will remove all the data. E.g., supposing the disk to be wiped is at /dev/hdc:

sudo dd if=/dev/zero of=/dev/hdc

will get rid of everything if there is no DCO/HPA.

The information stored in the HPA/DCO is usually put there by the manufacturer and so the HPA/DCO should not contain any of your personal data. I.e., you're probably fine just not worrying about the HPA/DCO and wiping with DBAN.

If you wipe the HPA/DCO you should still be able to install Windows afterwards, it should not damage the disk... I'm pretty sure of this... although I wouldn't bet my life on it...


The AWS API requires you to sign every HTTP request. The signature gives you two properties: authenticity and integrity.

It authenticates you because a valid signature can only be produced by someone who has the keyID/secret pair. It gives you integrity since the the request is first canonicalized (transformed to a standard form) and then signed using HMAC. Any modification to the message will result in the original signature being invalidated.

AWS signatures provide a defense in depth mechanism to TLS's integrity.

Some key differences follow. SSH is using asymmetric crypto as well while the AWS API is using a symmetric only. SSH will use key exchange and cipher negotiation while AWS does no such thing apart from using TLS. AWS authentication is "bolted on" HTTP while SSH is a complete protocol.

About how it works. This is all in the AWS docs, but here is a short summary. You construct your request, then you calculate a canonicalized form and finally use your key/secret to sign it. You add the signature to your original request and send it to AWS. The server will process your request: calculate the canonicalized form, fetch your secret from their storage, calculate the signature and compare it to the one you sent. If they match you are almost good to go.

Another thing they do is check the time and make sure this request is not being replayed. When you calculate the canonicalized form you also need to add the current date to it. AWS will check this date to make sure it is within an acceptable window. This limits replay to the given window.


I fortuitously accessed the configuration of unknown router: how come and what now?

Do a tracert,   you're connected because those two routers are probably routing between each other. The moment you logged in your crossed the line of legality. So yes it's illegal. You find the owner by asking around who set up the AP's.


Hiding database passwords for classic ASP connection strings

You should do it the same way you do everywhere else: use env vars.

Set O/S env var for user foo. Run application as user foo. Only foo or root can read that env var. Root can always read everything, including files.

Env vars are better than files as they are safer by default (ever screwed up a file permission?) and prevent you from accidentally checking passwords into source control, because you can't.

See https://stackoverflow.com/questions/6360036/getting-environment-variables-in-classic-asp

If you're opening child processes, pass them a clean environment.


Does the browser get the access_token in OAuth2?

The browser gets the authorization code, but not the access token.

For the OAuth2.0 Authorization Code Grant, suppose you're logged in to an app that will manage files you have stored on Google Drive.

The files are the resource
You're the end-user/resource owner
The app is hosted on the client server
Google is the authorization server

On the app you click 'Add files from Google Drive'. You get redirected to Google with the following information:

response_type ('code')
client_id
redirect_uri (hosted by client)
scope (in this case 'https://www.googleapis.com/auth/drive'; this is not a url, it just uniquely identifies the resource)
state (a random string to prevent CSRF)

You're now on the Google login page, where it will show the message 'App would like to access your files on Google Drive'. Upon successfully authenticating, you'll be redirected to the client at 'redirect_uri', with the following information:

code
state (from the previous step)

Now the client makes a request to Google. Note that the user agent for this request is the client's server, not the end-user's web browser. The client sends the following information:

grant_type ('authorization_code')
code (from the previous step)
redirect_uri (must be identical to the previous one)
client_id
credentials (the authorization server MAY accept any form of client authentication meeting its security requirements [1])

The authorization server returns:

access_token
refresh_token (optional)

Now you're back on the page you were originally on. On the backend, the client server can access all your files on Google Drive using the access_token it just received plus it's own id and credentials.  This access token never reaches your browser.

The OpenID Connect Auhtorization Code Flow uses a similar method, but instead of granting access to a resource, it allows the client to authenticate the end-user (think 'Sign in with Google').

Reference:

[1] https://tools.ietf.org/html/rfc6749#section-4.1


Silent (no user interaction) utility to clear cached credentials on Windows

The short answer is "no".

Cached credentials are maintained in special Registry keys.  These keys are only accessible by the SYSTEM account.  In order to impersonate the SYSTEM account, you must have Administrator access to the system.

You might be able to write a script or something that can bypass #1.  However, in the absence of any flaw in the OS (which cannot be reliably presumed, since it would likely be patched at some point), you cannot likely avoid #2.  And, since the cached credentials are stored in the Registry, #3 is non-optional no matter how you want to do it.

I believe you can get away without using the SYSTEM account, by modifying the configuration options that define how the system handles cached credentials instead of messing with the cache itself.  However, this will still violate your #2 & #3 requirements because the options are stored in the Registry and do require Administrator permissions to modify.  Additionally, it may require one or two re-logins or reboots to be effective.

Sidenote:  This question, as currently written, is perhaps more appropriate for Server Fault or Stack Overflow.  Nevertheless, the answer remains the same.

EDIT:  For more information about where the cached credentials are stored and how to modify settings which affect them, you may want to check out my related question on ServerFault.


Disallowing new password if it contains sequency of 4 characters present in 10 previously used passwords

Yes this can be implemented securely through the use of an HSM.  there's an existing question on this here


How can I detect which background application is using the camera, microphone or GPRS?

You could write an app to try and monitor what's happening on the device, but it would require elevated permissions for your app like running as System or requesting a large set of permissions, so that you could query the appropriate services and access system resources to guess at what other apps are doing. The packagemanager exposes api calls for determining the installed applications and even examining their permissions, At best though like mentioned in the earlier answer all apps run in their own instance of the dalvik vm. Access to resources on the system are also restricted by permissions both DAC and capabilities (in 4.3). Examining permissions or trying to see what apps are doing would be difficult, especially in the case of malicious apps that abuse poorly written legitimate apps

Even Google's measures for detecting malicious apps aren't foolproof though this quote is from a presentation at defcon

  In another bit of disturbing news related to Young’s research is the ability of an explicitly malicious app to get into the Google Play store and hang around for a while. According to reports, Young created an app to test the vulnerability and uploaded it to the Google Play store where it was clearly marked as malicious and users were warned not to install it. During the month it was available, until a user reported it, Google’s Bouncer service did not flag it as malicious. It is not clear whether the app was ever scanned by Bouncer or whether it “passed” the scan, but neither option reflects well on Bouncer’s effectiveness. Young also reported that most antivirus products for Android devices failed to detect the app as being malware, though one unnamed privacy application flagged it as having account access.

Modifying the platform would be the best way to try and detect malicious apps. SE for Android is project aimed at adding security and MAC to the android platform some of the concepts that they are exploring might be of interest.


Internet service providers do typically keep a detailed record of which dynamic IP address is assigned to which customer at any given time. However, in general they will only give out this information to law enforcement if they receive a court order, to protect privacy.

As for MAC address, the ISP probably also knows the MAC address of the home router used at that IP address (assuming this is a residential Internet connection). However, most likely they will not know the MAC addresses of any devices behind that router, as MAC addresses are only visible within the same LAN. These MAC addresses may or may not be logged by the home router, depending on brand/configuration.


Add certificate authority to one browser only

If you want to do that install Firefox. Firefox comes with its own trusted CA store and what you add there will only be available to Firefox.


If you're just using the cert for the public key, why bother calling validate?  If you want to know that the file isn't corrupt, it isn't... or you would have gotten a much different error.

The validate algorithm is upset that you have a Key Usage extension which does not specify the certificate signing usage.  In future revisions of the certificate, either add the certificate signing usage, or omit the Key Usage extension altogether.

If you were to edit the certificate to remove the extension then the signature wouldn't work for the public key, so the certificate would be self-issued, but not self-signed... which means there must be a parent certificate somewhere.  So it doesn't really solve any problems for you.  The effective answer is "no, you need the private key to re-issue a self-signed cert".

Experiment data:

ss_badku.cer

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 2818056532535039313 (0x271bbf7c52b85551)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=Experiment
        Validity
            Not Before: Jan 26 15:00:55 2018 GMT
            Not After : Jan 26 16:00:55 2028 GMT
        Subject: CN=Experiment
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (512 bit)
                Modulus:
                    00:9b:6a:6e:37:39:84:57:04:53:34:64:3e:73:f0:
                    76:c1:9d:04:e5:81:37:02:cc:6d:02:f7:5d:38:3a:
                    2e:b0:5f:5b:42:ad:67:52:cc:88:95:46:92:50:b7:
                    30:6b:c5:c6:36:e3:8c:48:24:6a:1c:5a:dd:92:1a:
                    25:44:c8:61:13
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication, Code Signing
            X509v3 Subject Key Identifier:
                5F:59:83:8E:FB:D3:13:BD:70:5F:E9:38:C3:A3:D9:49:F6:F4:BD:31
            X509v3 Key Usage: critical
                Key Encipherment
    Signature Algorithm: sha256WithRSAEncryption
         95:49:6c:90:bb:87:92:54:ba:c9:1b:a6:98:7a:9e:29:15:b7:
         b0:c7:75:fa:e2:66:4c:79:74:71:69:e3:17:cf:dc:6f:90:a2:
         f4:f1:7f:51:cd:7c:14:ed:6f:7d:32:55:55:41:8d:91:d2:31:
         2d:76:b0:6c:3f:76:6e:41:40:61
-----BEGIN CERTIFICATE-----
MIIBfDCCASagAwIBAgIIJxu/fFK4VVEwDQYJKoZIhvcNAQELBQAwFTETMBEGA1UE
AxMKRXhwZXJpbWVudDAeFw0xODAxMjYxNTAwNTVaFw0yODAxMjYxNjAwNTVaMBUx
EzARBgNVBAMTCkV4cGVyaW1lbnQwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAm2pu
NzmEVwRTNGQ+c/B2wZ0E5YE3AsxtAvddODousF9bQq1nUsyIlUaSULcwa8XGNuOM
SCRqHFrdkholRMhhEwIDAQABo1owWDAnBgNVHSUEIDAeBggrBgEFBQcDAQYIKwYB
BQUHAwIGCCsGAQUFBwMDMB0GA1UdDgQWBBRfWYOO+9MTvXBf6TjDo9lJ9vS9MTAO
BgNVHQ8BAf8EBAMCBSAwDQYJKoZIhvcNAQELBQADQQCVSWyQu4eSVLrJG6aYep4p
Fbewx3X64mZMeXRxaeMXz9xvkKL08X9RzXwU7W99MlVVQY2R0jEtdrBsP3ZuQUBh
-----END CERTIFICATE-----

ss_noku.cer

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 10026821066004793515 (0x8b266ca2999e88ab)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=Experiment
        Validity
            Not Before: Jan 26 15:00:55 2018 GMT
            Not After : Jan 26 16:00:55 2028 GMT
        Subject: CN=Experiment
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (512 bit)
                Modulus:
                    00:9b:6a:6e:37:39:84:57:04:53:34:64:3e:73:f0:
                    76:c1:9d:04:e5:81:37:02:cc:6d:02:f7:5d:38:3a:
                    2e:b0:5f:5b:42:ad:67:52:cc:88:95:46:92:50:b7:
                    30:6b:c5:c6:36:e3:8c:48:24:6a:1c:5a:dd:92:1a:
                    25:44:c8:61:13
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication, Code Signing
            X509v3 Subject Key Identifier:
                5F:59:83:8E:FB:D3:13:BD:70:5F:E9:38:C3:A3:D9:49:F6:F4:BD:31
    Signature Algorithm: sha256WithRSAEncryption
         72:a1:23:a0:00:c1:e0:dc:9a:11:21:4b:57:aa:42:49:c5:ae:
         05:e7:97:43:71:75:2d:33:b2:9f:96:4c:45:4d:80:91:51:5a:
         6f:bb:f3:03:67:10:f9:ac:f8:d5:00:b5:4b:85:10:2e:d7:45:
         d2:8f:e1:2e:0b:98:dd:e3:3e:fb
-----BEGIN CERTIFICATE-----
MIIBbTCCARegAwIBAgIJAIsmbKKZnoirMA0GCSqGSIb3DQEBCwUAMBUxEzARBgNV
BAMTCkV4cGVyaW1lbnQwHhcNMTgwMTI2MTUwMDU1WhcNMjgwMTI2MTYwMDU1WjAV
MRMwEQYDVQQDEwpFeHBlcmltZW50MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAJtq
bjc5hFcEUzRkPnPwdsGdBOWBNwLMbQL3XTg6LrBfW0KtZ1LMiJVGklC3MGvFxjbj
jEgkahxa3ZIaJUTIYRMCAwEAAaNKMEgwJwYDVR0lBCAwHgYIKwYBBQUHAwEGCCsG
AQUFBwMCBggrBgEFBQcDAzAdBgNVHQ4EFgQUX1mDjvvTE71wX+k4w6PZSfb0vTEw
DQYJKoZIhvcNAQELBQADQQByoSOgAMHg3JoRIUtXqkJJxa4F55dDcXUtM7KflkxF
TYCRUVpvu/MDZxD5rPjVALVLhRAu10XSj+EuC5jd4z77
-----END CERTIFICATE-----

ss_ku.cer

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 14221161353214574683 (0xc55bb6e75fde405b)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: CN=Experiment
        Validity
            Not Before: Jan 26 15:00:55 2018 GMT
            Not After : Jan 26 16:00:55 2028 GMT
        Subject: CN=Experiment
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (512 bit)
                Modulus:
                    00:9b:6a:6e:37:39:84:57:04:53:34:64:3e:73:f0:
                    76:c1:9d:04:e5:81:37:02:cc:6d:02:f7:5d:38:3a:
                    2e:b0:5f:5b:42:ad:67:52:cc:88:95:46:92:50:b7:
                    30:6b:c5:c6:36:e3:8c:48:24:6a:1c:5a:dd:92:1a:
                    25:44:c8:61:13
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication, Code Signing
            X509v3 Subject Key Identifier:
                5F:59:83:8E:FB:D3:13:BD:70:5F:E9:38:C3:A3:D9:49:F6:F4:BD:31
            X509v3 Key Usage: critical
                Key Encipherment, Certificate Sign
    Signature Algorithm: sha256WithRSAEncryption
         5e:eb:47:69:b0:65:c2:c1:d8:ee:85:0d:66:ae:76:96:ab:47:
         bc:dd:ea:2e:c8:f6:bf:1d:c2:1f:d3:e6:f0:ca:1a:80:5d:00:
         7c:a5:cd:2b:0d:b9:b1:31:84:f9:ed:75:72:5a:31:82:ef:c3:
         9e:7e:16:b3:68:aa:89:8a:80:52
-----BEGIN CERTIFICATE-----
MIIBfTCCASegAwIBAgIJAMVbtudf3kBbMA0GCSqGSIb3DQEBCwUAMBUxEzARBgNV
BAMTCkV4cGVyaW1lbnQwHhcNMTgwMTI2MTUwMDU1WhcNMjgwMTI2MTYwMDU1WjAV
MRMwEQYDVQQDEwpFeHBlcmltZW50MFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAJtq
bjc5hFcEUzRkPnPwdsGdBOWBNwLMbQL3XTg6LrBfW0KtZ1LMiJVGklC3MGvFxjbj
jEgkahxa3ZIaJUTIYRMCAwEAAaNaMFgwJwYDVR0lBCAwHgYIKwYBBQUHAwEGCCsG
AQUFBwMCBggrBgEFBQcDAzAdBgNVHQ4EFgQUX1mDjvvTE71wX+k4w6PZSfb0vTEw
DgYDVR0PAQH/BAQDAgIkMA0GCSqGSIb3DQEBCwUAA0EAXutHabBlwsHY7oUNZq52
lqtHvN3qLsj2vx3CH9Pm8MoagF0AfKXNKw25sTGE+e11cloxgu/Dnn4Ws2iqiYqA
Ug==
-----END CERTIFICATE-----

And the execution:

$ openssl verify ss_badku.cer ss_noku.cer ss_ku.cer
ss_badku.cer: CN = Experiment
error 20 at 0 depth lookup:unable to get local issuer certificate
ss_noku.cer: CN = Experiment
error 18 at 0 depth lookup:self signed certificate
OK
ss_ku.cer: CN = Experiment
error 18 at 0 depth lookup:self signed certificate
OK


Is there any inherent theoretical problem with this idea, assuming the encryption is immune to such things as collisions and related-key attacks?

Yes, there is a problem with this idea even given your assumptions.

Just use bcrypt for god's sake!

Some problems: The way you have stated your encryption "solution" seems to imply that you are just using a single key and no random IV or anything like that. In that case you are vulnerable to dictionary and other brute force attacks (you are still vulnerable even with a salt since the "hash" is likely fast). Also, with nothing to act as a "salt" you will be "hashing" the same password to the same "hash" each time, which is also bad.


If a hacker gets into my PC can he get to my saved windows live mail passwords?

Yes, but if a hacker gets into your PC, he or she can also install a keylogger that records everything you enter, so even if you did enter your passwords every time rather than saving them, you still wouldn't be safe.

The best advice is to practice safe computing and don't allow yourself to be infiltrated in the first place.

The next best advice is that if you're already past this point, or at any point determine that your system has indeed been compromised, Nuke It From Orbit, re-install and rebuild your system from the ground up.  This is the only way you can reasonably guardsmen it will be clean again.


What happens if you run out of password attempts?

This could help: https://support.samsungknox.com/entries/28604817-What-happens-if-I-enter-my-password-incorrectly-

It seems to indicate data stored in the Knox container will be deleted.


How to encrypt or store data so that only a pool of processes can share it on Windows?

If your threat model means your code has to run on a computer you can't trust, there is no way to protect your data: it simply isn't possible.

No matter what you do, the decryption key MUST be present in the memory of the system performing the decryption in order to access the data. This means that the only possible way to protect the key is to move that processing on some trusted hardware. Note that this doesn't really protect the data: as soon as it reaches the untrusted system in clear, it can be compromised. It only protects the encryption key.

You'll have to change your threat model by accepting the possible loss and simply making it as difficult as possible to access that data.


Public-key encryption for pre-shared keys with MAC

I believe you need both a general and a specific answer: general to provide a big-picture understanding of the solution and specific to guide you to particular tools.  Let's start with the big picture.

What you are describing is a signed and encrypted message which is accomplished with public key encryption.  The message is encrypted using the recipient's public key which ensures that only the recipient, using their private key, can decrypt it.  The message is signed using the sender's private key so the recipient can be sure that the message was sent by the sender.  The signature also contains a cryptographic hash of the message (encrypted with the sender's public key) at the time of the signing, which ensures the recipient that it has not been changed since the sender signed it.  If required, a trusted timestamp server can be used to add a timestamp to the message hash and encrypt the combination with its private key prior to the sender encrypting the signature so the recipient also knows when the message was signed by the sender.

NOTE: I provided a longer and somewhat clearer explanation of this process in another answer yesterday.

As far as algorithms, to code this at a low level you would need to use an asymmetric key algorithm (aka public key) of which RSA is certainly the best known, but you will need more to complete the process.  You need a hash algorithm [I recommend SHA-3.]  But you also need a higher level protocol that standardizes how the pieces are put together to ensure consistency and reliability.  These exist in a number of forms for various use cases, S/MIME, x509 and TLS are examples.

As you mentioned, you need an infrastructure to generate public-private key pairs and distribute them in a secure manner, referred to as Public Key Infrastructure (PKI).  There are a number of approaches to this that apply to different use cases.  For use inside a single organization, the Microsoft Active Directory system includes a certificate service that can issue certificates (which include the key pairs and have an expiration and a defined owner) and confirm their validity and ownership for other users.  In the public Internet environment, public certificate services are available from firms such as VeriSign, DigiCert, Entrust and many others.

Exactly how these pieces are put together is somewhat non-trivial.  If you are looking to code a solution, I urge you to research off-the-self encryption solutions that will provide the functionality you need.  Reliably building encryption code is not easy and it isn't necessary in almost all cases.  Robust solutions, both commercial and open source are quite common.

You will need to choose a hash algorithm.  I recommend the recently published SHA3 if at all possible.  Several other widely used ones have been cracked or at least shown to be weak in recent years, so it would be wise to use the newest.


The theory is that it reduces the amount of information available to attackers. A good traceroute can be most informative.

In addition, and in theory, every additional service running on a machine is a possible source of vulnerabilities. The thingumajig that answers ICMP requests is no exception, although they are mostly very old and small thingumajigs whose bugs got shaken out long ago.

As always, there is a decision to be made of security vs convenience. Is the small increase in security worth the inconvenience of breaking standard diagnostic tools?


How to determine which program accessed the Mac Camera?

Both Debian and BSD you can use lsof command.

In your articular case, you can run:

lsof | grep -i "AppleCamera"

Documentation of lsof related to your OS.


Need asymmetric encryption(not signing) where server encrypts and client decrypts

Despite your question title, you still want digital signatures, not encryption. You want something that the client can verify but not produce by itself; this is exactly what signatures are about. Trying to think about it in terms of encryption will only lead to more confusion.

The basic working of a license file is that it contains some vendor-chosen information that the vendor signed; the client uses the vendor public key to verify that the license file is genuine, then applies whatever policy is incarnated by the information in the license file. Typically, a license file would identify the customer and the allowed range of usage dates, possibly along with a unique identifier for the machine on which the software may run. The client code will then refuse to work if the current date is not in the allowed range, or if the local machine identifier does not match that what was specified in the license file.

As was pointed out, licensing can always be defeated in the case of software, because the code that enforces the license policy runs on the user's machine. If the user wants to bypass the license, he can reverse-engineer the code to simply deactivate the license check; this is about as impossible to prevent as music and video copying. Changing the local clock is the simplest form of "reverse-engineering", and even users with very little knowledge of programming can do that. If you want to enforce usage rules and licensing, then make it so that part of the code runs on your servers, not on the user's machine (but then, the software is no longer usable when offline).


Read NTFS / EFS encrypted files on iOS with saved certificate

EFS uses Alternative Data Streams (ADS), an NTFS feature that some third-party file system drivers have little-if-any support for. Even if the driver supports ADS, no guarantee that it also supports EFS, especially as that would require having somewhere to input the user's key. Each EFS file is encrypted with a unique key, and that key is itself encrypted ("wrapped") with the user keys of every user that has access to the file, and those wrapped keys are stored in ADS of the file; the EFS certs you backed up contain the user key needed to unwrap the file keys.

In theory, there's no reason that you couldn't use an iOS app to decrypt EFS files. First, The app would need to be able to access the hard disk in question (which is not a storage medium that iOS devices usually connect to). Then it would need to know how to access the ADS, how to read the EFS metadata, and how to import the user key (plus you'd need to supply the key and its password). From there, though, EFS uses a well-known (and somewhat outdated by this point) cryptographic cipher suite; an iOS app would have no problems handling it.

I don't know if an app with these capabilities has ever been written. It seems unlikely; iOS is very much not an OS built for this kind of work. Is there some reason you can't just use a Windows (or, next-best, Linux) machine to decrypt the files? On Windows it would be easy (just re-import the cert and user key), and on Linux I'm sure you could find a utility to handle EFS files.


Signing and key signing is done by different subkeys. You have:

$ gpg --list-secret-keys
sec#  rsa4096/0xDEADBEEFDEADBEEF 2000-01-01 [SC]
      Key fingerprint = DEAD BEEF DEAD BEEF DEAD  BEEF DEAD BEEF DEAD BEEF
uid                   [ultimate] My Name <me@example.com>
ssb>  rsa4096/0x8BADF00D8BADF00D 2000-01-01 [E] [expires: 2020-12-31]
ssb>  rsa4096/0xBADDCAFEBADDCAFE 2000-01-01 [S] [expires: 2020-12-31]
ssb>  rsa4096/0xFACEFEEDFACEFEED 2000-01-01 [A] [expires: 2020-12-31]

Here, DEADBEEF is the key of the whole PGP key, valid for Signing and Certifying.

Then you have three subkeys (ssb = Secret SuBkeys), valid for Encryption, Signing and Authentication respectively (you could eg. have a single subkey valid for both Signing and Authentication, but these are all on different keys for you).

When you gpg --sign, you are using BADDCAFE, whereas for a gpg --lsign-key you would need DEADBEEF. That's why one works while the other doesn't.

Now, I'm not sure why it is failing, it may be that DEADBEEF is not there at all (do you have an offline backup of the full key?), or perhaps it's a bug when interacting with the smartcard, and it is "not finding it", although it is really stored there.
An easy thing to review would be the number of slots that are supported by your smartcard, as on some of them you wouldn't even have enough slots for those four keys.


pubring.kbx is the public key database. Private keys are in private-keys-v1.d/. As the pubring.kbx contains all public keys, there is no such thing as a "corresponding" private key.

To interact with the keyring, you will have to use the gpg command. gpg -k will list the public keys, while gpg -K lists the private keys. When a public and private key have the same ID, they are corresponding key pair.

If you need the key(s) as a file, you can use gpg --export for public keys and gpg --export-secret-keys. You can also specify the key that you like to export, or use the -a option to get an ASCII (plaintext) output.


Storing Bob encrypted data, and send them to Alice (who must be able to decrypt the content)

Option A:

Bob uploads data to your site. It is stored encrypted with a key only known by Bob.
After some days/months, you notify Alice that there's some data to be received. Alice registers on your website (generating a public key).
Bob authorizes Alice account to read the data (uses their public to encrypt the secret from step 1).
The actual data can now be received by Alice.

Drawbacks:

Bob needs to trust that the account registered by Alice is actually owned by his dear Alice, not by e.g. an imposter from your company.
Bob needs to authorize Alice account (give her the key) after she registered.

Option B:

Bob uploads his data to your site. You provide Bob a link to download, containing the key.
Days/months later, Bob sends the link to Alice.

Drawbacks:

Bob itself needs to send that link to Alice. Or someone else on behalf of Bob e.g. he could program an email to be sent in 3 months (if supported by his provider).
Anyone in possession of that link could access the data. This could be easily solved by having your site verify Alice identity (you check that the access is performed by Alice and she needs the link for decryption).

If Alice already had an encryption key (such as a PGP key), that could be used directly, but it is unlikely that a normal user has one.


What real life scenarios require separate end user certificates for Signing and Identity?

The EBICS financial protocol (European alternative to SwiftNet) can be a pertinent real life example. It uses three certificates respectively for authentication, signature and encryption.

Most (if not all) banks use three different certificates. However the official protocol specifications allows the use of the same certificate for authentication and encryption, but requires the use of a separate certificate dedicated exclusively to signature:

  EBICS allows the use of three different key pairs per subscriber. In
  doing this, EBICS  promotes the use of at least two different key
  pairs for each subscriber:

  One key pair is used exclusively for the bank-technical electronic signature.
  The use of one single key pair is allowed for identification and authentication of the  subscriber by the bank system AND decryption of transaction keys.

This decorrelates the authentication and signature certificates, and allows to achieve the following goals:

The authentication identifies the entity acting as the unique sender of the request. This entity might be a physical person as well as an abstract entity (a company or a business entity for example), it doesn't matter.
In the case of a request sent toward the bank, the request must be signed by one or several physical persons (depending on several criterion) to be taken into account by the bank. It is possible that none of these persons act as the sender.
The authentication certificate may be stored on a disk, along with software configuration files or its database. This allows automatic processing like fetching accounts balance, last transactions status, etc. (these requests still require authentication, thus authentication certificate usage)
The signature certificate however, identifying the physical person, must be stored in a physical token (cryptographic USB key or smartcard) remaining in possession of this person and requiring a PIN code to be used.


SSL Labs no longer penalizes this
In a blog post dated 2013-09-10 SSL Labs project lead Ivan Ristic said:

Yesterday I changed the SSL Labs rating criteria to stop penalizing sites that do not implement server-side mitigations for the BEAST attack. That means that we now consider this attack sufficiently mitigated client-side, [...]

Details/Timeline

2011-08-23 BEAST is revealed
2013-02-07, SSL Labs: Vulnerability to the BEAST attack caps the grade at B.
2013-09-09, SSL Labs: Grade cap is removed.

SSL Labs version history is taken from their SSL Server Rating Guide PDF.


How to store and open files without making them recoverable?

I encourage you to read the VeraCrypt documentation, particularly the sections entitled Threat Model and Security Requirements and Precautions. A software's threat model defines what it protects against and doesn't. VeraCrypt's Security Requirements and Precautions mentions known vulnerabilities, attacks, and how to prevent or limit their respective damage.

Your operating system will store copies of opened files in the swap file, temporary folders, lists of recently opened files, etc, so recovery can be possible depending on what OS you use and how it's configured.

Full-disk encryption solves all of those problems, but also has vulnerabilities to things like cold-boot attacks.


You can't necessarily know if an email you receive is designed to be tracked but as tracking is limited to certain techniques, you can infer a higher probability of this behaviour if the email seems tailored towards such an end:

Email includes images that need to be downloaded remotely

Typically an email can have all images and formatting stored internally inside a multipart mime type container. So if an email doesn't do this and refers to external images that your email client must download then this might be an email with a web bug in it.

A web bug is any remote resource that the email client is encouraged to download for displaying the email; such that downloading it proves that the email was opened by the recipient. These can be 1x1 transparent GIFs that have a unique URL, such as http://spy.server/email-1234567890abcdefg.gif

Good desktop email clients will not download external images automatically without your permission to avoid this privacy risk. Webmail services may not provide this feature.

Email lacks some or all of its pertinent information, requiring online access

This isn't necessarily a bad thing, as banks will require you to login to their website to discourage phishing. But any hyperlink in an email can be used to track you if you click on it.

You may not know that an email is being tracked before you open the email unless your email client has fancy anti-malware features. The simplest approach is to set your email client to only render emails as plaintext. This gives you the opportunity to decide if the email looks legit and whether you trust the sender sufficiently to switch to HTML rendering on an as-needed basis.


Can a cloned page have HTTPS certificates?

...  have the certificates that ensure that his website is "secure" showing the green confirmation before the url in the browser?

It is still a common misconception that certificates ensure that a website is "secure".
Certificates and use of HTTPS do not say anything about the inherent security of a website. What they do instead is to protect the communication between the client (browser) and the server (website) against sniffing or manipulation by an attacker. Use of certificates also makes sure that the website displayed is actually the one which is shown in the URL bar.
But it does not make sure that that it is actually the site you believe it is or the site you've intended to visit. It does not protect against cloned sites or look-alike sites or similar looking domain names. Certificate issuers (CA) don't control what content is served on the domain, i.e. it is easy to get a certificate for sites serving malware, look-alike sites asking for your password (i.e. credential phishing) etc.
Certificates and HTTPS protect against insecure networks, like open WiFi hotspots or malicious internet providers. They don't protect against malicious websites though.


Sending data securely from a microcontroller to a server

Your idea of offloading IV generation to the server seems logical and fine. There are just a few things that I would like to add to make it more secure.

General rule of thumb is to use different keys for hashing and encryption.
What will you do if the keys used for HMAC/AES are compromised? Unfortunately, I don't have any easy to maintain/implement solution to that problem yet.
In the current scheme, someone can replay the HELLO SERVER packet and keep generating random IVs from your server. You can protect against it by encrypting your HELLO SERVER message by a fixed AES key and sending a timestamp in your packet.
You can maintain a timestamp/nonce in all of the messages to ensure nobody replays your temperature values/IVs. This will require your client and server to have a sliding window implementation for replay detection.
One possible optimization can be that the server generates a AES key and an IV on the client registration time. This will ensure that even if your key is leaked, the Arduino devices that are already registered are not affected.

For all of the above  points, consider the tradeoffs of security/developer time and then make a decision.


Do you think that there's something wrong with this idea?

Yes, quite a few points. Passing everything through TOR has the following consequences:

Much slower traffic, which on a public WiFi spot is killing
Constant security checks. Google, CloudFlare and Akamai all require CAPTCHAs. Every once in a while is OK, but on all requests can become irritating.
Blocked site that disallow TOR exit traffic.

TOR doesn't protect against people sniffing WiFi traffic at all. The TOR uplink can only be placed behind the WiFi access point. To prevent users from reaching each other you should enable AP isolation on the access point itself. Only allowing TLS/SSL/HTTPS etc.. traffic doesn't make much sense either. This limits users in what they can do without providing any additional security.


So, if the server's preferred cipher is RC4 and client provides a CBC cipher (Only one) will it select CBC or rejects the request?

If the server supports the CBC cipher that the client provides, the CBC cipher will be used. Otherwise, the connection will fail.

  If it chooses CBC then ir-respective of the cipher ordering (nmap's output) then it is vulnerable (?).
  If it chooses from client's ciphersuite ordering then definitely it is vulnerable (if it accepts CBC cipher) (?).

Every SSLv3 connection to this server using CBC cipher will be vulnerable to POODLE. For BEAST it is a bit more complicated as browsers may implement client-side mitigation.

  i) If server supports sslv3 and we have a CBC cipher anywhere in the cipher list given by nmap, can we say that the server is vulnerable to POODLE?

No. To be vulnerable to POODLE, the server must have support for a CBC cipher using SSLv3. If the server only supports RC4 with SSLv3 and CBC ciphers are only supported using TLSv1+, it won't be vulnerable to POODLE.

  ii) If server supports sslv3/tls 1.0 and we have a CBC cipher anywhere in the cipher list given by nmap, can we say that the server is vulnerable to BEAST?

Yes, but BEAST attack is not anymore a problem as every modern browser implements client side mitigation of the attack.

  What i am trying to understand is that based on nmap's output can i infer if it is vulnerable just seeing if it contains CBC cipher or is there any other sophistication involved?

Finally, yes:

SSLv3 + CBC = POODLE and BEAST
TLSv1.0 + CBC = BEAST

Example 1, the following configuration is only vulnerable to BEAST with TLSv1.0 if one of the CBC cipher suite is used:

PORT    STATE SERVICE REASON
443/tcp open  https   syn-ack
| ssl-enum-ciphers:
|   SSLv3:
|     ciphers:
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - A
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - A
|     compressors:
|       NULL
|     cipher preference: server
|   TLSv1.0:
|     ciphers:
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - A
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 256) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 256) - A
|     compressors:
|       NULL
|     cipher preference: server
|_  least strength: C

Example 2, the following configuration is only vulnerable to POODLE and BEAST on SSLv3:

PORT    STATE SERVICE REASON
443/tcp open  https   syn-ack
| ssl-enum-ciphers:
|   SSLv3:
|     ciphers:
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|   TLSv1.0:
|     ciphers:
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - A
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - A
|     compressors:
|       NULL
|     cipher preference: server
|_  least strength: C

Example 3 from nmap documentation, the configuration is vulnerable to POODLE on SSLv3 and BEAST on SSLv3 and TLCv1.0 is a CBC cipher suite is used:

PORT    STATE SERVICE REASON
443/tcp open  https   syn-ack
| ssl-enum-ciphers:
|   SSLv3:
|     ciphers:
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - A
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|     compressors:
|       NULL
|     cipher preference: server
|   TLSv1.0:
|     ciphers:
|       TLS_RSA_WITH_RC4_128_MD5 (rsa 2048) - A
|       TLS_RSA_WITH_RC4_128_SHA (rsa 2048) - A
|       TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 2048) - C
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 256) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 256) - A
|     compressors:
|       NULL
|     cipher preference: server
|_  least strength: C


How effective is Activesync Certificate revocation using CRL or OCSP

This page seems to indicate that when client certificates are used, then clients are authenticated by the certificate only, with no reference to any password (just like what is done with smart card logon). No password implies no failed password entry, thus no password-related lockout. Of course, as with all things Microsoft, this requires some thorough testing.

Whether devices will properly download CRL or OCSP responses depends on these devices, and personally I doubt they will. Note, though, that the device authenticates the server certificate; validation of the client certificate happens on the server, so that's the server which should download CRL or OCSP responses when client certificates are used. Microsoft's software tends to do revocation checks more or less properly (i.e. they reject the connection when the CRL cannot be obtained).

My cynical part tells me that the best practice with PKI is probably to run away as quickly as possible when X.509 certificates are talked about. It is known that maintaining a PKI is a lot of work. Microsoft's PKI (Active Directory Certificate Services) does a lot of things automatically and works best when all the involved systems are part of the same Domain as the CA.


Difference between SELinux booleans "httpd_can_network_relay" and "httpd_can_network_connect"

As Enigma says:

  The first option [httpd_can_network_relay] is used in an reverse proxy
  scenario in which your httpd is relaying requests to some backend
  httpd in behalf of the client.

As for httpd_can_network_connect, it allows httpd to make network connections, including scripts and modules.

Basically the output from audit2why is formatted in a strange way that made it hard to tell which description matched which boolean, hence the weird question based on that. I updated the question with the correct interpretation of that.


Does a commercially available self destructing HDD (set in BIOS) exist?

There is no hard disk drive, or a solid state drive, or any other non-volatile computer memory on the market that would have self-destruct capabilities and a casual customer could buy. There's also a good reason for this. Let's, as an example, see what a military grade RunCore's InVincible SSD does:

                     XBitLabs.com: RunCore InVincible SSD Features Physical Self Destruction Capability

  Besides typical elimination of all data through overwriting, the
  InVincible SSD can completely destroy the data by physically
  destroying memory and other chips inside the drive by burning chips
  down physically.

  The RunCore InVincible SSDs allow to protect sensitive data from third
  party access in two ways with a single click. One method is an
  intelligent elimination of all the data by overwriting the entire disk
  with meaningless code. This overwrite-deletion method ensures that
  there is no way to potentially recover previous data stored to the
  device, effectively setting the SSD back to factory default. Still,
  there are various data recovery devices not available commercially
  which can, perhaps, recover data even after overwriting.

  A less subtle method is the physical destruction of memory chips
  inside SSD by applying an over-current to the NAND flash memory and
  thereby physically destroying them.

Here is a YouTube video presentation from the manufacturer.

But let's make one thing perfectly clear. I'm not in any way endorsing this product. In fact, I don't know of a single store that would be selling them, the presentation documentation and the video are lacking on detail, credibility* and quality. And all of it was a bit of a joke among friends back when this story hit the web. If you watch the presentation video, you'll see what I mean for yourself.

But let's for a minute assume this drive is real, and it does what it says on the box. Would you be able to buy it as a casual customer? No:

This is supposedly how the circuitry looks like after self-destruction. There's been a lot of speculation on the web this image (the only one you'll find) was faked. I can't say it doesn't look like it was faked to me also. Note the PCB assembly helper lines (white) next to the storage chips that seem to have melted too.

  RunCore positions its InVincible SSDs for aerospace, military and
  general industrial applications, it is unclear whether the company
  plans to sell such SSDs to general public and whether the company will
  be allowed to do so.

There's a good reason for that too, considering it's at the very least a fire hazard, and if you'd use it in your laptop, let's not even consider what all would start happening, if you forgot about it and wanted to board an airplane (although same should be true for any other public transportation vehicles, possibly public places too).

* I didn't manage to find a single proof this product actually exists, or that the presentation slides and video were not faked, possibly as a demonstration of planned capabilities for military contractors.


ASCII Armoring in a little endian system

If the most significant byte of the return address is 0x00 you can still redirect the execution to execve in your example but you can't specify any arguments because they have to be after the address of execve. But this is impossible if the overwrite stops at 0x00. So the power of an attacker is very limited.


It is not a permission problem.
It seems that firejail handles blacklists automatically as soon as a single whitelist statement is issued.

For example:
If I don't issue any blacklist/whitelist, then all the /home/user folder is accessible in the jail.
If I whitelist /home/user/subfolder, then all subfolders in /home/user except ~/.bashrc, ~/.config, ~/subfolder and .Xauthority are automatically blacklisted.
This behavior was certainly not obvious from the man page.

In addition:
If I whitelist /home/abc, then /home/abc is still not accessible in the jail.
Only If I mount bind /home/abc within /home/user, it becomes accessible under the jail.
So any /home folder outside /home/user seems inaccessible even when whitelisted.
Again it is not very clear why firejail doesn't allow overriding the default blacklists.


over 100 scanner requests 5 min after domain registration

A few things, those scans might either be from your hosting company or third parties (e.g hackers). You might getter closer to the answer by clarifying if your hosting company offers some kind of automated security assessment. You probably agreed to such a service. Otherwise, your site is being probed for exploitable weaknesses by some hackers.


Firewall hole punching is what we call security through obscurity, which is never a good idea because your whole security mechanism may relay on the hidden information, which is in this case the process of opening a port in the firewall.

Because this process is hidden you may think your system is 100% safe. Think about cases such:

MITM - someone sniffing your data and taking notes of the hole punching process. Boom your security is gone with the wind.
Brute forcing the process - what happen if I try to guess your punching process? Remeber there are only 65536 ports.

You see? there is always a need for a lower/higher level security mechanism to protect your system anyway. Someone may argue it is a waste of resources only.

You get the idea...


Is knowing the BIOS password of help in hacking a computer *remotely*?

Usually not, but I can imagine some edge cases where it might matter.

As another comment mentions, some vendors provide interfaces all the way into userspace (reachable by normal programs and malware) to edit the bios config, those can be secured with a password.

Other answer:

  The only way to interact with the BIOS in order to use the password is to be physically at the computer.

I would argue that the only way to interact is through a HID. But to interact with an existing HID (or even emulate a new one) you don't need to be physically anywhere near it. See keystroke injection in wireless keyboards:
https://github.com/BastilleResearch/mousejack

A few Asus motherboards support cold boot from ps2, with usb to ps2 adapters still being used or Wake on Lan this becomes a practical remote attack. You could get a machine out of a powered-down state, and blindly enter the bios because of the predictable timing at boot.

Access to the BIOS could then be a way to set the system to boot from the network, bypassing the security model of the OS.

A properly used BIOS password would probably prevent that.


How to respond to repeated sql injection attempts

If it is happening too often and repeatedly it is most likely a bot, the thing is in first hand, if it is not important to you try to use least as possible query appended urls instead use myPage.php/3 3 will internally rewritten by your server or front controller. I am not saying it will solve your problem but it will save you from giving your variable names to internet.

And for now you should block any access on condition which are trying to input patterns you mentioned above. create a regex which matches the above input patterns and block them or warn them whatever you feel. don't do them manually if they are bots.


Is it secure to access web with Xubuntu in VirtualBox running in Windows XP?

This is mostly fine, but you have to consider a few things.

Firstly, the virtual machine accesses the internet presumably via the host, meaning the host has internet connectivity. This must be suitably firewalled, preferably relying on an external hardware firewall as exploits may be found in the XP (SP3) firewall that won't be patched.

You will probably need anti-virus running on the host machine if you are downloading files in the virtual machine that become readable/executable by the host.

If malware ever infects xubuntu, and this exploit can defeat the hyper-visor provided by virtualbox and then has the ability to infect an XP machine, then of course you'll be infected that way, although this is a rather convoluted and unlikely attack vector. Plus this could still be mitigated by anti-virus running on the XP machine that may prevent exploits even if OS patches aren't provided for them. This is because some anti-virus vendors will continue to create signatures for malware affecting Windows XP, in addition to heuristics.


In this case, the password takes the role of a symmetric encryption key. So you can use the recommendations for symmetric keys given by various trusted institutions.

For example, if you want to have a password of 128 bits of security, you can generate one of at least 22 alphanumeric characters (a-z, A-Z, 0-9). You can use a password manager for this, to ensure you do not introduce some bias in the generation process. (For the math: 128/log2(26×2+10) = 21.5)


Will Adobe have to re-sign all their previous publications?

It wasn’t their code-signing key that they compromised, it was the email key for their product security incident response email address. It’s embarrassing, but it doesn't affect the integrity of their code. In practice, that key is probably not used for nearly all the email that’s handled by that address, because PGP is only used by a tiny fraction of email users.


XXE Injection in docx: entity not defined

You probably are supposed to get an error. You just injected "something" into the xml parts of the docx file which the application(Word or Libre) isn't used to reading and thus it doesn't understand how to process and display that. If you're trying to test it, you should be uploading it to a Test Server with a vulnerable parser and then check for any pingbacks to your Server/Url.


How can the OpenSSL CCS Injection vulnerability (CVE-2014-0224) be exploited?

The idea of this attack is that it is taking place in the SSL handshake, hence the client is still not aware of the MITM and since the attack manages to downgrade the key of the encryption it will manage to make your client believe it is talking to the real server. So if someone manages to MITM your client with the client and server both using open ssl with the vulnerable versions its game over.

This blog post has a nice explanation and insite into the bug: https://www.imperialviolet.org/2014/06/05/earlyccs.html


Is TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 a safe cipher suite to use?

TLS ciphersuite names are structured in such a way that you can tell what algorithms and key sizes are used for each part of the handshake and encrypted session. Let's break this one down and see if there are any improvements we can make:

TLS - This doesn't signify anything in itself, but does allow me to mention that TLS 1.2 is the latest version of TLS and does not have any known vulnerabilities.
ECDHE - Elliptic Curve Diffie-Hellman with Ephemeral keys. This is the key exchange method. Diffie-Hellman key exchanges which use ephemeral (generated per session) keys provide forward secrecy, meaning that the session cannot be decrypted after the fact, even if the server's private key is known. Elliptic curve cryptography provides equivalent strength to traditional public-key cryptography while requiring smaller key sizes, which can improve performance. Additionally, they serve as a hedge bet against a break in RSA.
RSA - The server's certificate must contain a RSA public key, and the corresponding private key must be used to sign the ECDHE parameters. This is what provides server authentication. The alternative would be ECDSA, another elliptic-curve algorithm, but you may be restricted by the types of certificates your CA will sign.
AES_128 - The symmetric encryption cipher is AES with 128-bit keys. This is reasonably fast and not broken (unless you think NSA has backdoored AES, a topic for another time). Other than AES_256 (which may be too costly performance-wise), it's the best choice of the symmetric ciphers defined in RFC 5246, the others being RC4 (which has some known weaknesses and may be broken relatively soon) and 3DES_EDE (which only has a practical bit strength of 108 to 112, depending on your source).
CBC - Cipher Block Chaining mode. Here's where you can probably improve your choice. CBC mode is a way of employing a block cipher to encrypt a variable-length piece of data, and it has been the source of TLS woes in the past: BEAST, Lucky-Thirteen, and POODLE were all attacks on CBC-mode TLS. A better choice for performance and security is AES_128_GCM, which is one of the new AEAD ciphers introduced in TLS 1.2 and has good performance and security characteristics.
SHA256 - This is the hash function that underlies the Message Authentication Code (MAC) feature of the TLS ciphersuite. This is what guarantees that each message has not been tampered with in transit. SHA256 is a great choice, and is the default hash algorithm for various parts of TLS 1.2. I'm pretty sure that using SHA-1 would be OK here, since the window for exploitation is so much smaller than, e.g. the certificate signature. AEAD ciphersuites are authenticated to begin with, so this additional MAC step is not needed or implemented.

Essentially, you have chosen a good ciphersuite that doesn't have any practical problems for now, but you may wish to switch to an AEAD ciphersuite (AES-GCM or Bernstein's ChaCha20-Poly1305) for improved performance and protection against future CBC-related vulnerabilities.


Use Personal certificate without a key with Firefox

If you want to use a certificate installed in the Windows certificate store you need some kind of connector between the CryptoAPI provided by Windows and the PKCS standard used by Firefox.  One example is P11CAPI that was originally intended for smartcards but should work for any installed certificate in the Windows certificate store.

Once you download the DLL that matches the bitness of Firefox you use follow the instructions in the above link (paraphrased in part below) to use the Windows certificate store in Firefox:

  Inside Firefox, go to Options → Privacy & Security → Certificates → Security Devices → Load
  Enter a module name (I recommend "p11-capi") and browse to the .DLL file.
  Click OK enough times to close out the various dialogs that have been opened.

Edit: From v72 on: "Experimental support for using client certificates from the OS certificate store can be enabled by setting the preference security.osclientcerts.autoload to true."


Will this setup give better anonymity and hide tor usage?

In many (possibly most) cases yes, it will give better anonymity, but keep in mind that:

some degree of fingerprinting correlating the 2nd computer to you is possible through the analysis of your keyboard and mouse usage alone (even just mouse movement), and from your interaction with individual or multiple sites, when these interactions use the same Tor circuit
as you hinted at, the other fingerprinting methods will still be employable, they'll just won't be correlatable to what you've done and do through other devices. But all the activity you do through the 2nd computer will be correlatable.
Javascript will still be possible on the 2nd computer
either through Javascript or other ways the 2nd computer might get hacked, which would:

possibly facilitate hacking computer 1
allow to spoof anything that is being sent to computer 1, so that for example you might be thinking that you've posted something to a site, when you actually haven't
allow interception of anything you do through it, including for example the interactions with TLS sites
through the interception, facilitate your identification (analysis of anything you do with the computer, not just within the browser)
easily allow to see, even remotely, that it is communicating with computer 1

any adversary that can look at the 2nd computer's communications will get to know about the first one
of course, as you mentioned, the global adversary can always correlate
If you don't have physical control of the 2nd computer you don't really know what it's doing: it might well be sending all your traffic to someone, it might have backdoors/out-of band management facilities, and in general it might be very easy for someone else to interact with or spy on, even without any "hacking".

The hacking point means that you should care about the 2nd computer's security too.

The last point is instead actually a very serious threat that this model introduces.

For all your aims except Tor hiding and DNS leaks it would be better, with no drawbacks, to use a computer more under your control.

DNS leaks are easily preventable in other ways (Tor or VPN proxy), so I would ignore them here.

For Tor hiding you should keep in mind the alternative of passing through a VPN (either commercial or set up on a "2nd computer").

This has the drawback that it might be possible to detect Tor usage through traffic analysis (of the traffic between you and the VPN alone).

So ultimately you should balance the threats:
is it more likely and risky that my mere Tor usage gets detected by an adversary other than the global ones or the ones in control of the VPN/2nd computer (who have always other means of detecting it), or that the 2nd computer is accessible to or hackable by an adversary (which allows the interception, in clear, of everything you do through it)?


Sanitising a file/folder path from user input

I'm not sure exactly how you are performing your validation, so I can't give detailed steps.  However, there is a "best practice" here that I can direct you in anyway.
Principle of Least Privileges
Like all things, it's the difference between blacklisting and whitelisting.  The latter is rarely successful.  Whitelisting (or more generally, the Principle of Least Privilege) is always the way to go.  In essence what this means is that you don't want to try to stop the user from using some list of banned characters.  Instead you want to verify that the file/directory that they are actually trying to copy is in the list of permitted files/directories.
Work with the absolute path
They way I do this in similar situations is by taking the user input and "canonicalizing" it - let the OS convert it from a relative path to an absolute path, and then verify that the final, real, absolute path is actually an allowed destination.  Once you have an absolute path, verifying that it is an allowed direction is quite easy.  In the case of linux I would use something like realpath which does exactly that.  I'm not sure if I can guarantee that this approach might not still have edge cases (where realpath ignores an alternate encoding that scp doesn't, potentially leading to a missed exploit), but I suspect the risks will come down substantially.  How to actually implement this kind of check in your particular environment is another matter, and I can't help you with that one.
Small Gotcha
Also, you'll have to watch out for symlinks - if someone accidentally puts a symlink in your application that points to /, then scp will happily follow it and try to copy over your entire filesystem.
Another Approach
Of course all the above could be fixed even more easily by having a process run on the server that packages everything and then moves it off into a /backup directory to be copied out (per the comment from @domen)


Remember that VPNs just encrypt your communications between point A and B. In other words, your connection is confidential but not necessarily private.

Assuming that you are using a VPN that has no known vulnerabilities (i.e. logjam) even if you chained VPNs - which would be much effort for little gain - there are a few scenarios where privacy might be compromised (this is not a full list):

You used a payment method and contact info that is linked to you to sign up for the VPN service(s)
Using fake payment and contact info, you used a PC and IP combination that is linked to you to sign up for the VPN service(s) and your ISP logged it.
The target system (i.e. you  remote server A  remote server B  target system) pushes or injects tracking code to your end-point.

Depending on what one would want to be private from, much law-breaking would have to take place (e.g. steal login credentials, hack into someone's wi-fi, pc, or server) to achieve a reasonable high level of anonymity and/or privacy.

Finally, "secrecy", "privacy", and "anonymity" are similar but different concepts. I recommend watching and reading as much as you can by Bruce Schneier to learn more about these concepts.


Can you directly view a malicious PDF on Linux?

To say Linux is malware-proof most of the times is incorrect, it's just that much malware focuses on other OS'es (but there is nothing preventing an attacker from targeting more than one OS). Avoid opening the PDF on your box unless you are absolutely sure the malware wasn't written for and won't execute in Linux.

If you are trying to perform analysis then use a sandbox, such as Cuckoo. With that said, some malware is sandbox aware and will try to avoid detection/analysis.


How serious is "AtomBombing", and could AV be made to detect it?

It is important to realize a couple things:

Anti-Virus systems are not designed to prevent attacks nearly as much as they are intended to clean up damage after it has been done. In essence they are removing malware that is publicly known.

It is quite reasonable to write an Anti-Virus system to remove known malware even if it uses the Code Injection technique described in the linked article.

Sometimes there is malware that has not yet been added to the Anti-Virus program and cannot be cleaned up automatically. So it is always best to Nuke From Oribit if your computer was compromised. (back up important files first)
The 'flaw that cannot be patched', if I'm reading right, is not really a flaw at all, because it is only a logistic issue on what malware can do once it runs.

By some standards, if malware has run then it's no longer your machine (until you nuke from orbit) because it can already do so much damage, regardless of this 'flaw' in the linked article.

Running on a non-admin account can be helpful to reduce your risk. Admin accounts have access to the whole computer, while Standard accounts can be easily wiped safely. So if only the Standard account is compromised it is much easier to nuke just that one account.
Because Windows is a classical operating system, access restrictions are user-specific. Any process-level restrictions are usually an afterthought anyway, are less-frequently used, and have limited effect.

More recent operating systems like Chrome OS, Android, iOS use sandbox techniques and have proper app-specific access control. This way if you run malware it only has the permissions you granted. (note: sometimes the permission is quite inclusive, so be careful what you approve.)

Unfortunately, with a classical operating system, when you run malware it has access to the whole account. (or whole computer if it is an Admin account)

  Is this something new

Nope. "AtomBombing affects all Windows version."


Yes, it's a perfectly reasonable option. It's what AWS RDS, Heroku Postgres, etc does.

Like any software PostgreSQL could have pre-authentication remote exploits. You should keep up to date on patches and have a plan to upgrade to new versions. Run on a non-default port and if possible limit the IP address ranges allowed.

But in the end it's not too different to exposing something else, like an apache server.

However:

PostgreSQL is session-based. It expects clients to stick around and doesn't like it if they vanish without warning or stop responding midway through doing work. It won't crash or fail, but it'll do unnecessary work and the vanished connection may tie up resources for a while.
Unless you're quite careful the PostgreSQL protocol does lots of round trips. You can mitigate this with PgJDBC's or nPgSQL's batch modes, and I submitted a patch to libpq to add a batch mode to it too. But this latency will hurt performance.
PostgreSQL does more work pre-auth than some systems, and pre-auth connections count against the limit on max number of connections. So it's somewhat susceptible to DoS.

The first two issues also apply if you're using a VPN, they're not unique to TLS-based use.

For these reasons it may be worth running an application server close to the PostgreSQL database and bundling up application data requests into structured forms with json/protobuf/whatever requests and responses. This is most useful when clients are widely scattered and may come and go at random.

If you're not going to do that, set short timeouts on everything in Pg, be prepared to cope with retries, try to use batching and try to bundle work into bigger queries rather than lots of small ones.


As @Adonalsium mentions in the comments, Data Valet manages the Starbucks public WiFi. They're trying to redirect you to the "agree to terms" page to login to the WiFi. Go to a page in a web browser that is not protected by ssl (neverssl.com is great for this), and it will redirect you to the portal page so you can agree, and then this will go away.

The error is the security on your system working as intended, by blocking the connection to a server that isn't the one you were trying to connect to. When it asks something like "Do you want to proceed?", answer "No" or whichever answer will cancel the connection, to avoid sending secrets like authorization tokens to an untrusted server. Login to the portal as mentioned above, and then try again.

The name for the mechanism that redirects you to the terms page and doesn't let you go anywhere else until you agree is Captive Portal. Captive Portals are a common and annoying pattern for "protecting" public WiFi access points, but they have the annoying fault that they essentially need to conduct an attack against your connection to work.


The classical recommendation for a salt for password hashing is:

A random value of 128 bits or more;
obtained from a cryptographically sound random number generator (/dev/random or /dev/urandom on modern day Unixes);
unique for each entry (i.e. don't re-use the same salt, generate a new salt for each new password);
stored in plaintext in the database (so that the salt is available when verifying the hash).

There are plenty of past discussions of related topics. And most importantly, you should not implement your own password hashing scheme -- you should use a proven, well tested, peer reviewed implementation (bcrypt/PBKDF2).


Hashing email addresses for GDPR compliance

MD5 or SHA is not the concern. Hashes can be used for pseudonymization. The problem is that the hash would need to be salted (or peppered) so that data from other sources could not be used to identify the person.

My email is the same everywhere. A hash of it would also be the same. So that means that, in this case, the hash and my email become synonymous. Just like a username and the legal name of a person if paired. If you use a hash in this case, you actually gain nothing in terms of GDPR.

Hashing with a salt (or pepper) makes de-anonymising nearly impossible without knowing the added value. The salt (or pepper) almost becomes the token, in this case.

As always, check with your DPO.


What should be a good Open Source dependency scanning frequency?

I have never used Snyk, but I've used similar tools.
Running a scan on every pull request seems unnecessary unless that pull request is introducing a change to your dependencies. From my understanding of Snyk's documentation, Snyk scans your manifest files and uploads the dependencies and their versions. As Snyk's database of vulnerabilities is updated, it will alert you of any newly discovered or reported vulnerabilities in your dependencies. Unless you are adding, removing, or updating a dependency, you don't need to rescan.
The first question I would consider is how frequently you are changing your dependencies. If you are regularly changing your dependencies, then you may need to more regularly scan and upload the information from your manifest files to Snyk to make sure the reporting is accurate. However, if you don't change your dependencies often, then there may not be a need to scan as often. If the bottleneck is how long it takes to run a scan and upload the results to Snyk, I'm not sure that this action needs to be taken on every pull request.
If you really wanted the most accurate information, you could introduce some kind of logic to your build server to detect changes to your manifest files and execute a Snyk scan only on pull requests that introduce a change to your manifest file.
The more important thing, in my opinion, is how often you review the results from Snyk. It appears that Snyk does offer push notifications via email, Slack, and other tools when a dependency in your project has a vulnerability. This push notification could be useful to trigger your triage process to determine your exposure to the vulnerability and understand what you need to do to mitigate it.
If you've introduced Snyk to an existing project that has a lot of dependencies, you may be in a mode to play catch-up with updating to patch existing vulnerabilities. Rescanning on every pull request won't really help here, though, unless you're making lots of small pull requests to update each dependency and want Snyk to detect the change. I'm not sure that this is a good approach, though. I'd favor making sure that you have good automated test coverage, updating your dependencies, making any changes to your code to account for the new dependencies, and running both automated and manual testing to confirm that your changes are good. This is a good tactic if you have a large number of very out-of-date dependencies and are pulling major updates in - there could be a lot of work necessary to replace dependencies and it could be worthy of a release of its own.
Having a more robust process to control when dependencies are added and ensuring those dependencies are either free of vulnerabilities, the vulnerabilities are mitigated, or the vulnerability doesn't impact your system is also necessary. This doesn't necessarily require the use of Snyk. There are databases of open-source projects and their vulnerabilities - Snyk maintains one, as does Synopsis. Performing a lightweight vendor assessment to ensure that new dependencies do not introduce new vulnerabilities and you are only introducing dependencies that are well-maintained and offer an acceptable level of support is a good habit to get into.
After all of this, I would favor a nightly or weekly scan. On the more complex systems that I've worked on, running the full suite of all tests (from unit to system acceptance) takes a couple of hours. This testing happens on the development branch on a nightly basis. Integrating an open-source dependency scanner here can make sure that your reporting is always up-to-date, without introducing an extra step into every build. Developers can check in on the build every morning and triage failing tests as well as triage new vulnerabilities in dependencies. This can also be a good time to run static analysis on your code, and if you want to get very secure, deploy to a test environment and run dynamic vulnerability scanners.


How can I use a VPN connection on Eduroam?

How lucky! I just solved the problem myself looking here. This is a guide for the US but it works also in Italy.

I am using OpenVPN so i just had to connect on port 1194 with udp.


I suggest that you elaborate more on what is the threat model that could cause a great loss.  In general, I would question whether the web is the right technology to deploy this: failures of web security are commonplace, so if any security failure could truly cause a great loss of profits, maybe you should rethink the entire initiative.  But perhaps you can explain more about the highest-priority risks in your setting.  I imagine there is a server, and there is a client.  There are multiple threats.  We could worry about a malicious client that manages to change the authoritative copy of the data on the server.  Or we could worry about an attacker (perhaps a malicious client) that is able to tamper with the data that other clients see.  Or we could worry about a malicious client who is able to access confidential data, without authorization.  Or we could worry about break-ins to the server.  What are the highest-severity risks in your setting?

I'd also say that I'm having a hard time telling what your precise plan is.  I'm not familiar with what a "SSL certification" is.  Do you mean that you use SSL for all connections to the JSON data?  You also don't say how the encryption is done (details matter), or why you need encryption in the first place.  You also don't say if there is any access control, and if so, how that is done (how is authorization and authentication done?).  So there is not enough to review your system as the question currently stands.

Let me start with some general advice: given the potential for great loss to profits if there is a security failure, you need to hire an experienced security professional (perhaps as a consultant).  Give them full access to your system, and ask them to review the security of your system.  Ask for architectural risk analysis (threat modelling), source code analysis (e.g., for security vulnerabilities), and advice about how best to protect yourself.  If great profits are at stake, you shouldn't rely upon this web site.

Without any details, it is hard to provide specific advice.  But I'll make some suggestions:

Deploy a dedicated server to provide access to this data, and use it only for that purpose.  Lock it down tightly (there are many guides on this site on how to harden a server).
Use SSL sitewide: i.e., use only HTTPS, not HTTP.  Don't use HTTP for anything; use only HTTPS.  Enable HSTS.  Set the secure flag on all cookies.
Think carefully about how you will authenticate users.
Adopt good security practices, such as integrating security into the software development lifecycle.  Microsoft has some excellent resources.  Search on this site and you'll find more (Microsoft SDL, BSIMM, etc.).

Note that these will likely not be sufficient: it would be necessary to understand in more detail the goals and requirements for your web service to provide a more complete list.  This is just a starting point.


How to find out if your webcam and LED have been hardwired or not

if you are running linux

uvcdynctrl -c

May show LED

if so

LED_STATE: 0=Always-off, 1=Always-on, 2=Always-blink, 3=Auto on

then

 uvcdynctrl -d CAMERA_NAME -s 'LED1 Mode' 1

Should turn it on


A few things:

You might be interested in this link:  - seems PCI compliance scanners get confused about these issues sometimes.
Technically Beast applies to Browsers, but CBC is not what you want for your ciphers anyway.
However, CBC mode is default for FIPS complient RDP anyway :(
Yes, you definitely want TLS.

Without some more specific information about your setup, it is very hard to say what is breaking RDP (maybe that's more of a stack overflow or server fault kind of question anyway.... in fact check out this thread

However...

You want TLS 1.x for sure. DO NOT DISABLE TLS
Do your best to get rid of all CBC ciphers. They have inherent issues.

In Summary

No, the Browser Exploit Against SSL/TLS isn't typically used against RDP, but you should disable CBC, and enable TLS anyway. With the right tweaks, it seems that the optimal set up is possible.


in MVC or any other stateless web app

Your  terminology is rather confused. Any user facing application is a hierarchy of MVC patterns. MVC is rarely stateless, indeed in the cases where it is stateless (serverside) there's very little risk from CSRF. Your question is really about session management.

In the absence of session management, the only way I know of to solve the problem is via OTPs - but arguably this is session management since the OTP must be retained until it used, and the information about the OTP modified when it is used.

If you consider the case for pay-per-click advertising - you're not relying on any information being supplied by the user, however you do need to keep track of counts - hence the application is no loinger stateless. You can avoid the need to maintain a session by using (for example) browser fingerprinting - but you then need to maintain a list (state) of fingerprints already considered to have 'clicked' - the application is no longer stateless with regard to the client device and there is a session. It's really not that different from dropping a cookie on the browser and reading it back later.

Given that it also solves many other problems, maintaining a session serverside is the best solution.


This can be implemented in a bunch of ways, but all the ones you've listed are terrible on their own.

Private IPs are never going to be useful. Multiple users in different networks can have the same private IP. Public IPs on their own are also just as bad - they can be spoofed, or in several cases, are used my multiple people at once (large organizations frequently use single static public IPs for many users).

What you should be looking at is a combination of the following:

Public IP (store them so you know which is the user's most common login area)
Hostname
Screen resolution
Platform (mobile vs desktop)
OS versions (does the user generally use OSX but suddenly seems to have transitioned to windows?)

In fact, there's a lot of information that you can use. This site does a good job showing you what you can use.

Just remember - use a combination of the data that you recover. Don't just use IPs or OSes as the only way that you deny access.


Whether or not it contains an exploit, specifically, is irrelevant in the broader question of whether an OVA file can be malicious. The answer to the broader question is yes, absolutely.

The Open Virtualization Format specification gives you an idea of some of the potential vectors, but the obvious one is that it could map your entire OS disk to the VM and then, on VM boot, run code that exfiltrates it via the network or modifies files on disk to elevate privileges or drop malware (it doesn't have to adhere to your OS's security controls around filesystem access at that point). The VM could also map arbitrary USB devices to the VM (including inserted USB sticks) and use them however it likes.

If we want to go into more complex attack mechanisms, the VM could utilise platform vulnerabilities in the CPU, PCH, or memory (e.g. recent vPro/AMT bugs, or rowhammer) to effectively escape the VM environment and run arbitrary code on the host.

You absolutely should not run untrusted OVF VMs.


What happened with Kazakhstan's Root CA MITM policy?

(edit) A third round...
The Kazakh government made a third attempt at intercepting SSL traffic in December 2020. Again the primary target domains were large foreign tech sites such as Google, Twitter, Facebook, Instagram, and Netflix. Many citizens were notified by ISPs via SMS of the demand to install a new root certificate and traffic to some sites was blocked beginning December 6th unless routed though the man-in-the-middle attacked government endpoint.
Officials gave the excuse that during the COVID-19 pandemic cyberattacks targetting "Kazakhstan's segment of the internet" grew 2.7×. On December 7th browser manufactures again announced they would blacklist such certificates.
(edit) Update...
The state sponsored MITM attack described in the answer below was dropped on August 7th, 2019 (approximately 3 weeks after being started). During that time several hundred sites, largely email, communication, and social media sites were intercepted. The government of Kazakhstan officially stated that their "test was completed" and "was a success" and noted that citizens could uninstall the offending root certificate.
As of later August major browser vendors including Mozilla's Firefox, Google's Chrome, and Apple's Safari all added the certificate to a hard coded internal black list so that it would not function even in the event some people leave it "installed" on their local machines.
Original Answer...
As the previous answer suggests, the 2015/2016 attempt at this stunt got so much backlash they basically backed away from it and it sat for a while. The original January 1st 2016 deadline came and went with no real enforcement. Their request that Mozilla trusts their root certificate was declined. The MITM attempts still cropped up in individual cases of sites put under surveillance, but nothing widespread.
Until July 2019! Apparently, they never let go of the idea itself, the project was resurrected, and in the last few days enforcing started en masse through many ISPs (first implementation seen on July 17th, 2019). See this Mozilla bug report for technical details, Hacker News for discussion, or this ZDNet article for the news take.
Here is KCELL's (a major telecom company in KZ) information page in English that is a sample of what locals are being prompted to do when trying to access sites that have been MITM'ed.

Pursuant to the Law of the Republic of Kazakhstan On Communications and clause 11 of Rules for Issuing and Applying Security Certificates, Kcell JSC informs its customers of the need to install Security Certificate on devices capable of connecting to the Internet. According to law, telecom network operators are to ensure that customers with whom the operators have service contracts are able to install the security certificate on their mobile devices.
We draw your attention to the fact that installation of the security certificate must be done on each device that will be used to access the Internet (iOS/Android mobile phones and tablets, Windows/MacOS personal computers and laptops).
Customers failing to install Security Certificate on their mobile devices may face technical limitations when accessing certain websites.

Is spite of reports that it would be mandated first only in the capital (Nur-Sultan, formerly Astana) the enforcement seems to be rolling out on a per ISP basis, and has started impacting other cities as well. Bulk SMS messages have gone out (mostly to Nur-Sultan area subscribers) with instructions on how to add the government root cert to many cell phone OSes.
The certificate they are demanding everybody install is identified as Qaznet Trust and distributed through qca.kz. While the demand that all HTTPS traffic be intercepted is a governmental one and the root CA certificate in question is a Kazakhstan government-controlled one, it should be noted that the actual interception is being implemented by ISPs. Technical details of this are still not clear, but this likely means that each and every government authorized ISP will be able to intercept data from all website traffic.


How can I ensure that my Python web application source code is secure?

Either of those methods should be sufficient, assuming your webserver is set up properly and does not allow users to drop into and view the file system structure.

If you want to compile the code into an executable, and ensure the developers of the compiling software can't get the code sent back to them, set up a development system as a virtual with all of the software you need, but none of your code.  Shut down the virtual, make a copy/clone with a full copy of the virtual hard drive.  Fire up the copy, remove the network adaptor, and connect it to a separate virtual drive (this drive should be in a separate folder and you'll place your code onto it the first time you use it).  Do all of your work on the clone, copy the executable to removable storage (USB, CDROM, etc), then place the finished work on the webserver.  At least once a month shut down and delete the clone system (taking care to preserve the separate virtual drive with your code), fire up the original virtual, complete any OS and application updates, and create a new clone (doing the same steps of removing the network adaptor and connecting the virtual drive with your code).


As a student, how do I safely and responsibly disclose a serious security issue in a school environment?

I have many years experience working within a college ICT team. This is what I would recommend based on my experience.

I wouldn't go to management, they won't care or a non-technical manager will overreact and take the issue on as a personal mission. Additionally if you are worried about being accused of 'hacking' it is non-technical management who are most likely to do that.

I would recommend documenting the security flaw and submitting it to the ICT service desk.

If you do not have access to the service desk as a student, then email them directly or just chap the door of the office and explain the situation to them and they will advise you on how to proceed. (Chapping the door is probably the best option) They will probably just raise a ticket for a technician to have a look at the issue, it will go through the escalation procedures from there.

Do not be worried about about bringing this issue up with them, even if it turns out to be nothing, most teams will be happy for the proactive reporting of these kind of flaws. From experience I can say that most in academia be it support staff or academic staff only raise faults with ICT when it affects them personally.

I have discovered faults in the past, only for a member of staff to tell me that the fault in question has been there for months. My response was always the same, "Well why didn't you raise a ticket with ICT to fix it?"


Infection through Virtual machine in NAT mode

VM box --(virtualnetwork)--> Linux VM with iptables (NAT and restrict only port 80/443, etc) --(nat/bridge)--> Host PC

This will ensure infections in your VM box cannot spread laterally.

And also make sure your user accounts in the VM box are not the same as the ones on your network.


Is Yahoo SignIn Seal effective at phishing prevention?

It seems to me that the "correct" attack would be to emulate the behavior that is seen when you attempt to log in on a browser without any cookies already present. This effectively deactivates the "sign-in seal" completely, falling back to the default behavior.

This is the experience users see every time the user starts up a different browser or different computer or clears their cookies (either manually, or because of intervention from some zealous "anti-tracking" tool), so the user will certainly be familiar with it.

Sure, it's slightly different from what you normally see, but you've seen it often enough to recognize it as "real", and there's no other way forward than to put in your credentials anyway. After all, that's what you've done every other time you've seen this screen and it's been the correct behavior every other time.

So, not foolproof, but I'd say this technology is at least a step in the right direction. Not a perfect one, but you could argue that it's better than nothing (you could also argue that' it's not, but there you go). At least they're thinking about it; that's further along than we were several years ago.


No, banks tend to use somewhat different technologies from the rest of the world. This doesn't necessarily mean that they use weak cryptography: banks tend to be good at risk management, and to put just enough money in security to make attacks rare without putting so much that security would cost more than the attacks that it would prevent. (As a customer of banks, the flaw in this approach is that it doesn't take account risk for the customer — that only enters the equation when banks are worried that some customers will be so unhappy that they'll change banks, which itself has a high cost for the customer.) For example, a lot of banking protocols still use 3DES when most of the rest of the world has standardized on AES.

The current standard used by major banking card providers is EMV. EMV uses some well-known building blocks: 3DES, SHA-1, RSA. This has been the standard protocol suite in Europe since the mid 2000s; a lot of other countries have migrated since then or are migrating. Many cards and terminals also support various legacy (often national) protocols for backward compatibility. Security is only as strong as the weakest link in the chain. Banks are pushing for EMV adoption by shifting liability for breaches to merchants when legacy protocols are used for a transaction, in order to convince merchants to renew their equipment to a newer generation that supports EMV.


How does an SSL server prove its identity?

The SSL handshake implies the use of certificates; the server has a certificate which the client shall validate (with regards to its known trust anchors, aka "root CA"). The certificate contains a public key and the cryptographic algorithms used in SSL that the connection is secure in the following way:

The client knows that whatever data it sends and receive will be usable only by the server which owns the private key associated with the public key it received (within a certificate).
The certificate proves to the client that the said private key is owned (controlled) by some entity whose name is written in the certificate; for SSL, the name is a DNS name such as "www.example.com".

It is still up to the client to check that the name in the certificate is the name of the server that the client intended to contact in the first place.

Analogy: you meet someone who tells you that his name is Bob. You ask him to show you an ID card. Verifying that the ID card is a genuine ID card is not enough; you also have to check that the name on the ID card is indeed "Bob". Otherwise, Charlie could tell you "I am Bob" and show you his ID card with the name "Charlie".


Is there any security risk with adding a **root's** public key to the local user's authorized_keys (so root to login as a user non-interactively?)

No, for the following reason: root could patch sshd to always try root's authorized_keys file as well as its own.

Of course if root's private key gets stolen you have a bad day. Don't allow that. You would be much happier if root's private key only exists in /root on the server.

If someone can become root they can steal it but that's of no account because they can do far worse. For example, patch sshd to take a hardcoded authorized key for any account.


How Digital Certificate is bound to a particular identity?

This is really an often overlooked mechanism.

The way a digital cert is bound to an identity is by digital signature from a certificate authority.

A certificate authority (CA), is an entity which is entitled to sign and 'vouch' for the identity of other entities.

They act as a trusted party.

Even more interesting is that for this whole system to work, all OS/browsers ship with a list of trusted 'root' certs, or certs of certificate authorities :D

Here's a list of all of the root certs Apple trusts.

Certs are thus bound to domains in the context of web/TLS.

Certs are not necessarily bound to domains, in other contexts certs may be bound to different identities. Its just common for TLS/SSL server certificates.

For example, Hardware Security Modules (HSMs) may create a secure channel and bind certs used for that to IP addresses or pin their fingerprint. In code-signing certificates are bound to legal entities e.g. Google Inc. –

Not very decentralised is it!


Deciding CVSS v3 scope parameter for a few OWASP top 10 vulnerabilities

Scope in CVSSv3

Scope is defined in the documentation:

  When the vulnerability of a software component governed by one authorization scope is able to affect resources governed by another authorization scope, a Scope change has occurred.

Examples

  1) SQL Injection: Changed.
  Vulnerable component: Webserver/database server
  Impacted component: Web application. Can cause webapp to be non-available.

I would disagree with your reasoning, but would agree that the scope is changed.

The vulnerable component is the web application: The vulnerability wasn't introduced by the server, nor by the DBMS, but the issue exists because the web application inserted user input into an SQL query.

The affected component is the database, as it governs the data it holds, and an attack can extract information from it that shouldn't be available. If system commands can be executed or if files can be uploaded, the server would also be affected.

Other opinions:

CVE-2015-8604 is rated as unchanged scope.
High-Tech Bridge rates SQL injections as changed scope in a blog post about CVSSv3.
High-Tech Bridge rates SQL injections as unchanged scope in their CVSSv3 calculator.

It can be seen that there is at least some unclarity about rating the scope of SQL injections. I haven't found any other examples that determine the scope of an SQL injection.

  2) XSS: Changed
  Vulnerable component: webserver
  Impacted component: browser

Makes sense, and this is also how First rates it in their XSS example.

  3) Unvalidated Redirects: Changed.
  Vulnerable component: webserver
  Impacted component: browser (malware can be downloaded)

This also makes sense, for the same reason as XSS.

  4) CSRF: Unchanged

This also makes sense, and is also how First rates it in their CSRF example. The vulnerable and the impacted component are both the web application.

  5) Session Fixation: Unchanged

This also makes sense, for the same reason as CSRF.

  6) Insecure Direct Object Reference: Unchanged

This also makes sense, for the same reason as CSRF.

  7) Unrestricted File Upload: Changed
  Vulnerable Component: web server
  Impacted Component : could be host OS

This makes sense.


How to safey interface with compromised USB device?

Yes, in general you'd use an air-gapped system that is specifically used for analysis (and not your daily machine for writing reports etc.).

There are many methods: Use a Virtual Machine, run the analysis OS from read-only media, run the analysis OS on write-blocked media, or re-image the analysis machine after use. What you use will depend greatly on the resources available to you, and your technical knowledge.

An easy way is to boot from a Linux CD or similar to do the analysis (disconnect physical drives and network interface devices if you feel that would be necessary).

If you're concerned about remote connectivity via cellular network, contain the modem inside anything that can serve as a Faraday cage to block the signal.

Finally, cellular modems are pretty cheap these days compared to the cost of your time required to analyze it. If you suspect it is compromised, and your objective is to have a good, working cellular modem, consider just buying a new one.


Identification of TLS POODLE Vulnerability

Poodle attack works on SSLv3 although there is a variant of poodle attack on TLS that appeared in recent years by accepting incorrect padding after decryption.

nmap is checking the TLS/SSL version. You can find the script of poodle identification rules online.

It is recommended to completely disable SSLv3 on server side.  On the client side, you should always upgrade to the latest version. Also, most of the browsers/servers use "TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks" to prevent any intentional downgrade of version and drop the connection.