How do large companies protect their private (code-signing) keys? Some time ago I read the canonical answer of our ursine overlord concerning CAs and their private (root) keys.

More recently I stumbled across the question on the question on how to manage code signing keys for iOS and android.

Basically as a follow-up I just had to ask myself:

How do large companies (like Apple, Microsoft, Google, Intel, ...) protect their valueable code-signing keys?

In particular this question can be broken down into: How do these companies ensure only valid builds get signed (i.e. access management) and what do they physically do the protect the private keys? In particular the comparison of the security measures root CAs use and that the companies use can be interesting.

This question is also motivated by my older "How do large companies protect their source code?", where I got interesting, unexpected answers such as "they just use private GitHub repositories". In particular one may suspect that the build machine just has a software key that signs all builds it produces and I hope to clarify this (among learning the actual protections).

As for "why" protecting the keys is important:

If Apple's keys would get lost (silently?) anybody could sign iOS or Mac OS X builds or Apps, which would undermine large portions of Apple's security measures.
If Microsoft's keys would get leaked, the same app fiasco as for Apple would hold and additionally attackers may be in a position to push malicious Windows updates to targeted machines.
If Intel's keys were leaked, it would be possible to sign Intel processor code updates and to sign arbitrary SGX software allowing deep implementation of malware in a target system that is impossible to get rid off without changing the hardware.
If Google's keys were leaked, one could arbitrarily fake Google apps (arguably the weakest attack scenario out of the given)

As usual, I don't want answers saying "it's illegal to steal / abuse such keys", as the law may not be an effective way to stop agencies that can just declare their law violation "top secret"  or to stop criminals who don't care about the law anyways.

Further, I want to quickly clarify, why I rule out "revocation" as the solution: a) This is not always possible, especially for hardware manufacturers, if the public key is actually hard-coded (for security reasons) into the hardware. b) The damage to the image of the company would be gigantic if they would have to revoke a key. Thus, while revocation may work in some circumstances (for small app developers for example), it's not a good option for larger companies.

Lots of processes can be called "code signing", anything from publishing a tar file with a pgp-signed hash and up.

For the sort of large company you mention, ultimately HSMs (more than one, obviously, in case a data center is overtaken by zombies or something) are involved. The hard part is not where the actual keys are stored, but the entire Release Engineering process that guarantees that the shipped signed binaries really did come from the source code in the repositories.


What's the difference between Secure Boot and Attestation? What's the exact difference between secure boot and device attestation. Nowadays with secure devices both are used, even at the same time, when in the core they do similar things, which is verification of the software running on the platform.

While both of them aim for verifying the authenticity of one or multiple software component(s), they are totally different mechanisms and that is why, as you mentioned, they are both deployed in the same time in some platform.

Here I give a platform-agnostic comparison between the two concepts:

Secure boot:

is allowing only a trustworthy sw to be executed. => it verifies the software which is expected to run on the device.
Secure boot is conducted during the boot process of the device (just after the power up).
Secure boot propagates the trust from one software component to an other which results in building a chain of trust.

Remote attestation:

a host platform attests a verifying platform about the trustworthiness of the SW running on that host platform. => verification of a software which is already running
is usually done in a post-boot process.
measurements to be used in the attestation protocol are generated during the Secure Boot process.


Should an administrator be able to turn off TFA for a user We use Google Authenticator and SMS for two factor authentication. Should we allow the administrators of the site to turn off TFA for users?

Google Auth uses SMS as backup option but SMS does not have a backup and when the user cannot receive SMS for whatever reason he/she cannot login. I know we can backup SMS with voice calls but these situations might still arise.

Should we allow the administrators of the site to turn off TFA for users?

This is a very interesting question. I suspect the answer very much depends on the individual site's risk assessment. Let's look at some pros and cons of allowing the administrator to turn off 2FA for an individual user.

Pros

Convenient for the user if he loses access to his authentication token.

Cons

Subject  to phishing attacks. An attacker could call/email the customer service representative and pretend to be the user asking them to turn off the 2FA. You might think your customer service representatives are smarter than that but you will be surprised. Mat Honan is living proof that this is a very real threat.

However, there might be a legitimate use case in which the user has lost access to his authentication token and needs it to be reset somehow. I would make the user go through the same process as he would need to when resetting his password. This could involve emailing him a link to trigger to process or something similar. The idea here is to make it as difficult for an attacker as possible to do this as he will need to compromise the user's email account as well.


FIN Scan: sneak through certain non-stateful firewalls? Many resources stated that FIN scan can bypass non-stateful firewall:

In Nmap document:

  The key advantage to these scan types is that they can sneak through certain non-stateful firewalls and packet filtering routers.

Also in Wikipedia :

  FIN packets can bypass firewalls without modification.

But I don't know which property of FIN scan makes the bypassing possible?

Also I found in an answer to the other question, it mentioned that the FIN scan is an older attack, does it means nowadays FIN scan is much less useful facing the new version firewalls?

TCP FIN exploit a subtle loophole in the TCP RFC to differentiate between open and closed ports. Page 65 of RFC 793 says that "if the [destination] port state is CLOSED .... an incoming segment not containing a RST causes a RST to be sent in response." Then the next page discusses packets sent to open ports without the SYN, RST, or ACK bits set, stating that: "you are unlikely to get here, but if you do, drop the segment, and return."

This is indeed an old way to circumvent packet filtering, and the industry has made this scan (mostly) obsolete. Like any other scan, the idea is to try it and see if this works, and compare with other scan type to understand if a port is really close or open.

  When scanning systems compliant with this RFC text, any packet not
  containing SYN, RST, or ACK bits will result in a returned RST if the
  port is closed and no response at all if the port is open. As long as
  none of those three bits are included, any combination of the other
  three (FIN, PSH, and URG) are OK. Nmap exploits this with three scan
  types:

  Null scan ( -sN) Does not set any bits (TCP flag header is 0) FIN scan
  (-sF) Sets just the TCP FIN bit. Xmas scan ( -sX) Sets the FIN, PSH,
  and URG flags, lighting the packet up like a Christmas tree.

  These three scan types are exactly the same in behavior except for the
  TCP flags set in probe packets. The key advantage to these scan types
  is that they can sneak through certain non-stateful firewalls and
  packet filtering routers. Such firewalls try to prevent incoming TCP
  connections (while allowing outbound ones) by blocking any TCP packets
  with the SYN bit set and ACK cleared.

Source: Nmap Network Scanning: The Official Nmap Project Guide to Network Discovery and Security Scanning


Is this website vulnerable to an SQL injection? I have a SquirrelMail server setup, and when I play with the mailbox parameter in the following GET query

example.com/src/right_main.php?PG_SHOWALL=0&sort=0&startMessage=1&mailbox=Drafts%2Ftest

I get the following error message (image attached as well):

  ERROR: Could not complete request. Query: SELECT "Drafts/test" Reason
  Given: Mailbox doesn't exist: Drafts/test (0.001 + 0.000 secs).

I was wondering whether this could mean that the site is vulnerable to a SQL injection, and what commands I could try to verify this.

I'm afraid there isn't much information to go on here in terms of answering your question. SQL injection vulnerabilities make themselves visible through very specific error messages, showing the server's inability to handle the SQL query being passed to them. As a corollary, in order to find that error message, you'll need to make sure you're querying on something that will transform into SQL and inject itself into the server.

It sounds like SQL injection attacks might be something you're not too familiar with, so I'd suggest doing a little more background research. I find this Computerphile video to be especially educational on the topic. And to try out SQL injection on an application that is vulnerable, I'd play around with Juice Shop (from OWASP).

Hope this helps! Feel free to ask any more questions you have on this.


TrueCrypt VS LUKS Bruteforce Resilience I have been researching LUKS vs TrueCrypt topics -- my only concern is security, but most of the discussions I see focus around usability / interoperability .

I know TrueCrypt has a bunch of nice passphrase features -- slow hashing algorithm, thousands of iterations, options for multiple keyfiles etc.  These features make me feel that secret key security of the encrypted data is quite strong.  But I do not know what LUKS does in this respect.  I know in TrueCrypt if I make my passhphrase "abc" the final encryption key will not be "abc" it will be the result of some slow hash -- but if I use LUKS what will my key look like if the passphrase is "abc".

(This is a hypothetical example, I don't intend to use a three character passphrase ... I just need to demonstrate my point -- please no discussion of weak passphrases here, I know all about that, assume I will use the maximum amount of characters for any passphrase, LUKS or TrueCrypt.)

Also, I know TrueCrypt offers other features, such as multi-layered encryption with different algorithms and different keys.  That sounds like a really good measure, does LUKS have any option like this?  When I install the OS (MINT) I only have a checkbox option yes or no to encrypt.  I don't see any further configuration options when installing.  What are the defaults?

My primary concern here is that while I know a bit about TrueCrypt, and how it works with regards to my security desires, I have no idea how LUKS behaves.  Let's say LUKS out of the box does not offer multi-layer encryption or slow hashing, is there a way to enable this post-install?  What does it entail to change the LUKS configurations from an existing weaker installation to a stronger one more suited towards the features of TrueCrypt that appeal to me?

To re-iterate, I don't want a discussion of usability.  Yes, I have heard the discussion of "poor usability is poor security", but in this case, even if my data isn't so sensitive it needs to be hidden from extra-terrestrial hackers with state financing. Consider this a practice environment to teach myself the strictest and most secure setup.  If I suffer a usability related security weakness (human error) then I am to learn from such a mistake.

Thanks for the input, it's always very appreciated.

The answers you're looking for can be found in the Cryptsetup documentation, but to summarize:

LUKS uses PBKDF2 to derive a "slot key" from your password, with a default iteration count sufficient to take one second on the computer that created the LUKS volume.
This "slot key" is unrelated to the key used to encrypt your data.  It is only used to decrypt a copy of the volume master key, which is then used to encrypt/decrypt the data.
You can have up to eight different passwords for unlocking the volume.
Each slot key can have its own derivation function.  If you find that one second of PBKDF2 doesn't fit your needs, you can add a new password with different parameters and erase the old one.
There is no support for changing the encryption on a LUKS volume after it has been created.
When creating a LUKS volume from the command line, you can specify the cipher used.  The default is "aes-xts-plain64" (AES-128 encryption in XTS mode with no hash function).  LUKS does not support layered encryption algorithms.
LUKS does not support hidden volumes the way Truecrypt does, but given that everyone and their dog knows about Truecrypt's hidden-volume support, these "hidden" volumes can't be considered at all secret in the real-world (as opposed to the information-theoretic) sense.


Privacy and security risks of Green Card scanning with or without offical RFID protection envelope The presentation slides by Bishop Fox at RFID Hacking - Live Free or RFID Hard - 01 Aug 2013 – Black Hat USA 2013 – Las Vegas, NV briefly describes a number of RFID hacking approaches, and ends with a picture and statement about the sleeves that are now distributed with United States Permanent Resident Cards ("Green Cards"):

USA - Green Card Sleeve
• Since May 11, 2010, new Green Cards contain an RFID chip
• Tested Carl’s “protective sleeve”, doesn’t block anything.
• False sense of security

But details are hard to come by.

Questions:

Does the official sleeve provide any protection? Has it been quantified?
What alternative protective shielding alternatives might work better?
Which RFID technology, protocol, etc is used by Green Cards?
What are the privacy and security risks of using Green Cards with or without the official sleeve, or others that might be recommended?

For starters, it appears that Green Cards and passports from many countries use the ISO/IEC 14443 NFC protocol in some form. Wikipedia documents a number of common but optional protection mechanisms for Biometric passports, but notes attacks on them, e.g. allowing attackers to clone a passport by examining and scanning the unopened postal mail package in which it is delivered.  See Radio-frequency identification


How to allow only some specific computer systems to access website? I need a process to allow only certain computer systems access to the website irrespective of the network they are using.

Much like a Licensing system, I can provide a private key or something similar to the user, which the host server should identify that key by matching from a list of private key. Alternatively could the website hosting server can use the MAC address of system?

Client Machine can have any OS installed. I am familiar with PHP but open to using any programming language

Any ideas are welcome

You can't do it using the MAC address - these are not visible across routers. Even if you were on the same LAN, it doesn't solve the problem (as posted) since it's trivial to change a MAC address.

The big question is how closely you need to stick to your requirement.

There are lots of solutions such as simply authenticating the user, using authentication devices (such as RSA keyfobs), client side certificates - but these methods can be transferred between machines. Browser fingerprinting makes it more difficult, and something like evercookie makes circumvention more difficult (but more likely to fail to work in the first place).

Really we need to know more about whether it's the device or the user you need to authenticate and how strong the requirement to disallow duplicated access is.


SQL Injection with an uninjectable URL I was recently given a subdomain to try and exploit with SQLi: gov.ns.agency. Unlike what I would see in most tutorials, I can't really inject parameters into the URL like I would see everywhere else.

Here's what I tried:

At the login page, any username sufficed with password: ' OR '1'='1 and I'm directed to gov.ns.agency/users. Here a form returns whether a user exists. I'm supposed to get info from columns 'name' and 'pass' from table 'users'. There's a hint also that MySQL is the database and the requests sent are GET and not POST with the exception of some queries which return a 500 Internal Server Error.
'UNION ALL SELECT NULL,version()'--returned MySQL version 8.0.11 - omitting single quotes would return 'user not found'.
'UNION SELECT 'Found', COLUMN_NAME FROM information_schema.columns WHERE table_name = 'users' AND column_name LIKE 'pa% returned [name]Found -> [priv]pass. I'm still scratching my head over what 'priv' is, it might describe privileges? admin perhaps?
'UNION ALL SELECT NULL,concat(schema_name) FROM information_schema.schemata'
this would give DB names but instead gave me a 500 Internal Server Error.

I'm quite new to penetration testing and I'm not sure which query would get the tables and even how I'd use tools such as SQLMap or Burpsuite to do it, or even how I'd approach this kind of site where I can't even inject queries into the URL (normally ending in .php?id=123) so any tips would be greatly appreciated!

sqlmap -u "http://vuln.url/x.php?param1=..."

You can add --dbms parameter like --dbms=myqsl if you're sure about the database used or --forms to inject the form in the page.


User Authentication API I'm developing a web API for a user database that will be used to verify a given username / password combination is valid.

I'm just looking for comments / criticism on the following method that I'm planning to use:

API Key records are stored within the database
Each API Key record consists of a public API key and a private API key
API clients use the private API key to salt the hashing of the given username / password
Username, password, and public API key are sent via HTTP GET request to the API for validation
A custom response code is returned based on what happens at the server

Is this a secure way of proceeding?  Any advice is greatly appreciated.

Always use HTTP POST for sending data to the server.GET should be used for fetching the data.
You should always use HTTPS for your web service.

  API clients use the private API key to salt the hashing of the given username / password

If you are referring to the private key of your authentication server then this is a wrong approach.The private key of the server should not be kept with the client.If you are using a secure connection then you need not perform password hashing on the client side and let your server handle the load.

here is a good reference for password hashing techniques and using the salt.


Is There a Whitepaper or Explanation of ECDSA somewhere? Let's say I wanted to write an implementation of ECDSA from scratch to better understand it. I can't find a raw, non-abstract explanation anywhere. I tried tracking down the sources on the wiki article and going through some posts and explanations on here, but I can't find anything of substance. Where do I find basic information on this?

If you have access to IEEE Xplore or any other digital libraries that hold technical papers, I would say that is your best bet, as they usually explain concepts or implementations mathematically and algorithmically. If not, I found somebody's thesis online as a start, maybe he cites potential free resources  available in the bibliography.

http://www.nicolascourtois.com/bitcoin/thesis_Di_Wang.pdf


when a web application is vulnerable to RFD (Reflected File Download)? As far as I understand, a webapp is vulnerable to RFD (Reflected File Download) only when the header Content-Disposition: attachment which force the download is set in a response with JSON body,
but in any case we want to save a plain JSON file in the user computer ?
and giving a significant name to this file via Content-Disposition: attachment; filename="whatever.txt" really mitigate the attack ?

As far as I understand, a webapp is vulnerable to RFD (Reflected File Download) only when the header Content-Disposition: attachment which force the download is set in a response with JSON body,

Not necessarily.

See for example this article which states that IE 8 and 9 will download all JSON as file, and that the download attribute on a link can be used to force a download in other browsers.

I tested this with a current version of Firefox, and at least there, it does not work cross origin (except via right-click -> save as). If you can post HTML links to the original origin, an attack is still possible using Firefox. I can't test on Chrome, but there it should work without that.

  but in any case we want to save a plain JSON file in the user computer ?

An attacker wants to save a file on the users computer with a name - and extension - they control and with content they at least partially control, and they want this file to be delivered from a trusted domain (by the vulnerable application) so that a user will trust and execute it.

  and giving a significant name to this file via Content-Disposition: attachment; filename="whatever.txt" really mitigate the attack ?

Yes. The idea of RFD is that an attacker can determine the filename of the file so that it contains a malicious extension. If you set the filename, that is not possible. I am not aware of any bypass which would allow an attacker to overwrite the given filename.


How to sign and encrypt mails using firefox There is an option under Tools>options>Advanced>Security Devices. How to use that to encrypt and digitally signed your emails.

I believe you misunderstood the Firefox function.

Firefox itself is not a mail client, therefore it doesn' provide you with ability to encrypt and/or sign your emails; use Mozzila Thunderbird with Enigmail and OpenPGP plugins if you're looking for this kind of functionallity.
Here's nice how to: https://securityinabox.org/en/thunderbird_main

The Security Devices function is used for the purpose when you wan't to use different password and certificate manager than the default Firefox one, I believe for example KeePass or something like that.


Pros/cons of using a private DNS vs. a public DNS I was wondering why a company should use a private DNS.

In comparison with a public DNS, which advantages does a private one have, and which issues can a public DNS create for a company?

I'm new at these concepts of networks security, so maybe this is a very basic question.

DNS is a very broad topic, even when you narrow it to have a security focus, however I will attempt to address this in a way that will make most sense to you.  If you are looking for a very high level introduction to DNS, I would suggest this.  For a little bit more detail, check this out.

First of all, you may want to be aware that Private DNS vs. Public DNS can be construed to mean multiple things.  The first thing that I thought of was split-horizon DNS, where you use the same DNS name for internal and external, but provide different information depending on the source of the DNS request.  There are other options, however, such as choosing to use completely different names internally and externally (such as example.com publicly and example.local privately).  I have seen both implemented in corporations, however having completely separate internal and external DNS servers and namespaces is preferred from a security point of view.

You would typically want to keep your RFC1918 addresses only in your private DNS, as well as your private addresses which are Internet-accessible.  This is less important with IPv4, but with IPv6, having Internet-accessible IP addresses is much more widespread (although not necessary).

Essentially, it boils down to the fact that you would want a private DNS infrastructure in order to serve employees, so that they would not need to memorize the IPs (or VIPs) of every service.  You would not want these DNS entries available to the Internet because it could be used for enumeration or discovery (see section 2.6), among many other reasons.  The security of a system is said to boil down to some basic concepts, and you must keep in mind that, if you release certain information, if it allows anybody to compromise the CIA triad.

There is also the option of an extranet DNS infrastructure, which would be for partner companies, or companies that you do business with on a regular basis.

Finally, public DNS is provided as a service to your customers, again, so that they will be able to contact whatever it is you are providing.  A couple of security concepts to keep in mind with DNS include:

DNS Open Resolvers and Amplification attacks
DNS Cache Poisoning Attacks
Zone transfers from rogue DNS servers

There are many, many more types of attack when discussing DNS, but I feel like the previous few are a good starting point.  If you are interested in DNS security, I would also point you to this write-up, and also DNSSEC.


If nmap reports a port is open, does that ALSO mean a service is listening on the port? I have a Thompson TG585v7 router/firewall whose firewall is configured to FORWARD  several ports to a computer X54 within the LAN.

These ports are in the range 1024 through to 2500

That X54 computer is now gone and so there is nothing "listening" on those final destination ports

If I use scan the firewalls public IP using

nmap -A -p 1000-2500 219.xxx.xxx.xxx

Output

$ sudo nmap -A -p 1000-2500 219.xxx.xxx.xxx

Starting Nmap 6.40 ( http://nmap.org ) at 2015-02-21 13:14 NZDT
Nmap scan report for dsldevice.lan (219.xxx.xxx.xxx)
Host is up (0.011s latency).
Not shown: 1500 filtered ports
PORT     STATE SERVICE VERSION
1723/tcp open  pptp    THOMSON (Firmware: 1)
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: broadband router
Running: Thomson embedded
OS CPE: cpe:/h:thomson:st_585 cpe:/h:thomson:st_536i
OS details: Thomson ST 585 or ST 536i ADSL modem
Network Distance: 1 hop
Service Info: Host: SpeedTouch

It reports other fully functioning - in this case 1723 - ports that are open and have a service listening, but doesn't show these ports that are forwarded to a non-existant machine.

So My question is, if nmap reports that a port is "open", does it mean that both the following is true?

the firewall is accepting connections on the given port
there is a machine/service listening on the other end

For a SYN scan of the sort you are performing, nmap defines an "open" TCP port as one where a SYN packet sent by nmap elicits an ACK packet from the target system.  Assuming that the firewall is configured sensibly, and that the TCP/IP stack is programmed correctly, an "open" port means that yes,

the firewall is permitting connections on the given port
there is a machine listening on the other end

and additionally

there is software on the other end listening for data sent to that port.

If you want a greater degree of certainty, have nmap perform a "connect" scan (-sT).  This is a slower technique that establishes a full TCP connection with the target, as opposed to the "halfway-opened" connection of a SYN scan.  If a "connect" scan says the port is open, it's open in any meaningful sense of the word.


What are the security implications of storing multiple hashes for similar passwords? I've seen it mentioned a number of times here that an approach to preventing forced password changes from being changed to trivially similar passwords (eg, mysecurepassword1 gets changed to mysecurepassword2 and so on) is to hash multiple variations that can be later compared to. That can be done by looking for patterns and doing things like incrementing numbers, adding them, etc.

I'm curious what the implications of this is on security. These hashes would give more opportunity for a brute forcer, wouldn't they? They're essentially collisions. Although on the other hand, you'd expect that if someone is brute forcing, they'd probably try the varitions around a similar time, so it seems like it wouldn't necessarily save much brute forcing time. I'm also unsure how much even collisions would matter if the password is secure enough. Eg, if we have 10 variations hashed, that theoretically means that it would take 10x fewer attempts to brute force the password, right? But the scale of magnitude of time that is needed to brute force a secure password is often so large that even a 10-fold decrease is still an impractically large length of time.

So yeah, does hashing these variations significantly weaken security? Is it small enough that it doesn't matter (particularly compared to the benefits of avoiding similar password reuse)?

If there is any impact on technical aspects of security, whether positive or negative, it appears to be very marginal. I qualify "technical" because human/psychological elements often play a significant role.

The real impact is only the real user - whose life is made marginally difficult and perhaps on the plus side, more security aware.

From the server side, I see this as extra work (both during development and operations) that doesn't quite give enough benefit to justify it. To defend against any moderately talented attacker's dictionary attack, the number of hashes that need to be stored this way is too large to make sense at scale.

Why? The attacker's work factor hasn't changed much, despite you having eliminated "some" of the combinations.

OTOH, user awareness can be better handled on the client side by rating the password strength while the user types it in. This can include both entropy tests (length, variety, etc) as well as uniqueness tests (variation of previous password). No need to store it on the server side, IMHO.


Is a full name and address all that's needed for identity theft? It seems knowing a person's name and address is pretty much all that's needed for identity theft, no?

Couldn't those two variables enable one to pose as another person successfully? Given so, it makes it much, much easier to steal someone's identity with such easily obtainable things than would be for other difficult means (like phishing, hacking someone's personal account/computer, etc.).

Simply knowing an address where a person lives and their full name seems to be all that's needed to kickstart identity theft, and from what I can tell both of those things can be extremely easy to get.

So is a name and an address linked to that name all that's needed to steal a person's identity?

Imagine, for example, that you call a bank to say that you forgot your account number, but you provide the name of the person's account you're looking for plus their address and account type. Isn't that halfway to accessing someone's account already? I'd imagine not much else would be needed. They can't ask for social security number over the phone, and this sounds like a thief's dream.

How much is needed in order to perform "identity theft" largely depends on what you're qualifying as "identity theft". Regardless of this, it also depends upon what a given service provider requires for identification & authentication when someone contacts them for service on an account or to open new accounts.

Sometimes, name and address are indeed all that's needed. Sometimes, it's more. Sometimes, it may arguably be even less.

As for jump-starting identity theft, you don't even need that much. Just a person's first and last name can be enough. For some publicly-searchable databases - government-provided ones, no less - that's all you need to look up records which will contain ridiculous loads of additional PII. You might have a hard time nailing down a particular individual by name alone if theirs is common, like "John Smith". But it's a pretty fair bet that you can easily find whatever you want on a (hypothetical) "Joaqim Sikowicz" without knowing anything else about them.

As a particular example, I recently had to search for certain records regarding a traffic incident. Using only a person's first and last name, and a government-provided, publicly-accessible website that requires no registration, I was able to find:

Full Name (First, Last, Middle, Suffix)
Physical Address
Date of Birth
Telephone Number
Driver's License Details (Number*/Class/Expiry)
Physical Description (Race/Gender/Height)
Vehicle Description (Year/Make/Color/Style)
VIN
License Plate (Number/Expiry/State)

*-About the Driver's License Number, it's worth noting that these can often be simply derived from other trivially-obtainable PII. A quick Google search will turn up several sites where you might be able to do this with as little as: Name, DOB, Gender.

Also be aware that there are (or at least appear to be) zero restrictions against asking for one's SSN over the phone. I've had it done to me several times. Usually this is during a first-time account setup, but occasionally it's also happened for verification purposes where I have a pre-existing account. Where there's already an account established though, it's generally more common to just get asked for the last four digits.


When visiting an HTTPS page for the first time, why isn't there a prompt for the certificate? I installed a fresh Windows 7. I wonder why when I visit website using HTTPS, I do not get asked to accept their certificate like shown on this picture:

Because your browser comes with its own set of certificates.

When you install a new version of Windows 7, it comes with Internet Explorer.

Internet Explorer, like any other browser, comes with its own set of certificates that it trusts.

All the web authentication is based on the fact that there are only valid certificates in your browser.

How does authentication with certificate work?

When you access an https link, the server you access send its own certificate.

This certificate is signed using asymmetric cryptography with the private key of a trusted entity.

The certificates that ship with your browser ARE your trusted entities.

So when you receive a new certificate, you ask the trusted entity (certificate)

if they can validate the identity of the certificate you just received.

Here the certificates stored in your browser act like public keys. If one of the public key can verify

the signed certificate, you know that it was issued by the trusted entity that created this public key.

Fun thing

You need to protect the certificates stored in your browser (trusted entity).

If a malicious user can insert its own certificate it could impersonate the

server your are trying to reach and do an attack called man in the middle.

The only thing protecting you against that is the fact that all the trusted entity in your browser are valid.

Here is a good example of how this attack can be done:

How can my employer be a man-in-the-middle when I connect to Gmail?


Parameters for PBKDF2 for password hashing I use PBKDF2 with SHA-256 to store hashes of passwords. I use the following parameters:

number of iterations desired        = 1024
length of the salt in bytes         = 16
length of the derived key in bytes  = 4096

But recently I found out that most probably the parameters are badly selected.

For example wiki page says:

  standard was written in 2000, the recommended minimum number of
  iterations was 1000 .... As of 2005 a Kerberos standard recommended
  4096 iterations

which means that most probably I have to increase this number

and

  The standard recommends a salt length of at least 64 bits

Which means that my salt length is ok is too low (thanks to Neil Smithline). But when searching through the standard I was not able to find the mention about recommended salt length.

When I looked for the length of the derived key and found this nice answer:

  If you use PBKDF2 for password hashing, then 12 bytes of output ought
  to be fine, with a non-negligible security margin

it suggested me that I took too big number which probably does not make sense.

So my question is: can anyone show good parameters (may be with some justifications/links) for this scenario of password hashing (as of 2016). Also can I guarantee that the derived key length will be always the same length as I ask?

Your starting point

PBKDF2-HMAC-SHA-256
number of iterations desired        = 1024
length of the salt in bytes         = 16
length of the derived key in bytes  = 4096

Algorithm
Ok - PBKDF2-HMAC-SHA-256 is a solid choice, though if you're running on any modern 64-bit CPU, I would strongly recommend PBKDF2-HMAC-SHA-512 instead, because SHA-512 requires 64-bit operations that reduce the margin of a GPU based attacker's advantage, since modern GPU's don't do 64-bit as well.

Salt
16 bytes of salt is fine, as long as it is cryptographically random and is unique per password.  Normal recommendations are in the 12-24 byte range, with 16 considered quite solid.

Output and Iterations
4096 bytes of output is ACTIVELY BAD!  SHA-256 has a native output size of 32 bytes.  PBKDF2/RFC2898 states that in this case, you'll first run 1024 iterations to get the first (leftmost) 32 bytes, then another 1024 iterations for the next 32 bytes, and so on for 128 times in total to get the full 4096 bytes of output you requested.
So, you did 131072 iterations total, and got 4096 bytes of output.  The attacker is going to do 1024 iterations total, and compare their 32 bytes of output to the first (leftmost) 32 bytes of your output - if those are the same, they guessed correctly!  You just gave every attacker a 128:1 advantage!
Instead, if you're happy with the speed, you should do 131072 iterations with 32 bytes of output - you will spend the SAME amount of time you are now (so it's free!), and your attackers will need to spend 128 times more time than they do now!

NOTE: If you move to PBKDF2-HMAC-SHA-512, you can use up to 64 bytes of output, and each iteration will take slightly longer.

Never get more output for password hashing than the native output of your hash function, i.e. 20 bytes for SHA-1, 32 for SHA-256, 64 for SHA-512.  You can optionally store less, but it doesn't save you any computations.  I would recommend storing at least 28 bytes of output (224 bits, which is twice 112 bits, the nominal security of 3DES).
Note that output length values are pure binary output - BEFORE you BASE64 or hexify them, if you do (personally, I'd store the raw binary - it uses less space, and requires one less conversion).


Does broken site functionality pose any security threat? If you are assessing an application as a part of pentesting exercise, how do you deal with broken site functionality? Should the issues be ignored?

Is keeping functional bugs in a system safe?

Broken functionalities in a web application are not a security threat per se, but they might be one. For you as a penetration tester, look out for:

Information leakage about the system (stacktraces, version numbers, error messages, file paths, ...) as they might help an attacker
Missing security features (if the functionality to change the password is broken, then you should include this in your report)
System crashes (DoS)
And generally any unexpected behaviour.

As each and every line of code (and therefore each feature, whether working or not) increases the attack surface of the application, the client should avoid to deploy (partly) broken features to their servers.


Is there any potential harm in opening up junk emails in Outlook in the browser? I check my emails in Chrome using outlook.com, and occasionally I read through the emails marked as junk, both to see if they are junk, and to laugh at the amusing phishing attempts.

Could I be putting my computer at risk by opening up these emails? I never download any attachments or click any links.

TL;DR It's possible depending how your browser and email client handle files. Remote images are a potential risk with targeted attacks.

It depends on the security of your browser and other factors.

Risks of Remote Images
There is the possibility your browser will view remote images. These images could be unique to that specific email and be used to let a spammer, phisher, etc read your message. They could get your IP Address and try to get more information this could be used as part of a targeted attack against you. Remember databases with IP Addresses get leaked all the time. If your attacker is smart enough and has the right resources they could steal your identity all with only an IP Address.

Browser Security / Web Client Security
If you are using an outdated browser if your email provider does not properly strip malicious inline JavaScript (emails can use HTML therefore inline JavaScript) you could become infected if a security issue in your web browser exists.

Attachments
Many attachments such as .docx files could be infected to install malware on your computer. You shouldn't open unknown attachments. You can scan first with VirusTotal even then please only open them at your own risk.


User mail certificates policy: Is expiration+renewal better than no-expiration+revocation? In our environment, we provide user certificates to sign or encrypt emails. This is an internal setting, meaning the CA is internal to our organization (not a public CA) and handled by our Active Directory PKI.

User certificates are emitted with a duration of one year and automatically renewed by the PKI.

There is however a side effect in Outlook: Whenever a user open an email that was signed or encrypted by a certificate that has since expired, Outlook do not check to see if said certificate has been renewed and issue a warning message stating that the certificate is invalid requiring the user to force the displaying of the message and ignore the warnings.

This is a very bad thing for user education and awareness ("ignore Outlook certificate warnings...")

Given I did not found a way for Outlook to behave properly, I am considering an alternate solution: Issue certificates with unlimited (very long) duration, this way a user certificate will become invalid only after revocation by the PKI (when the user leaves the organization).

This looks like an appropriate policy, but are there any side effects? I did not found any recommendations / best practices by Microsoft so I am wondering if others have experience with this setting and if it is useful to set expiry date for internal user certificates.

The reason for the certificate's current invalidity is not relevant.
If Outlook, or any client software, presents a different conclusion regarding the validity of a signature from either type of certificate (expired, or revoked) then the software is broken and a bug report should be filed with the vendor.

If the signature was made while the certificate was valid, then the signature should (IMnsHO) be accepted as valid; if the signature was made after the certificate became invalid, then the signature must not be accepted as valid.
The tricky bit is establishing when the signature was made relative to the invalidation of the certificate. It's likely that there is no simple solution; I expect something like this proposed distributed timestamp mechanism or this longstanding timestamps-by-email service would be useful.

It's probably going to require more user education in any case.


Asymmetric Cryptography as Hashing Function Could I replace password hashing with the following strategy:

Generate a public/private key pair, store the public key as the "salt" and destroy the private key. Maybe we could even not generate the private key in the first place (we only need to know it mathematically exists).
To store a password: encrypt the password using the public key. That is practically irreversible as nobody has the private key.
To authenticate: encrypt the potential password with the same public key then compare it to the stored encrypted password. This assume the asymmetric cryptographic algorithm always produce the same encrypted text for a given clear text. (i.e. that encryption is a function)

This would provide the following advantages:

Asymmetric cryptography is usually more expensive than hashing and should therefore require less stretching for the same benefits.
Stronger guarantee on the entered password: there is one and only one password which can be accepted. That is, no collision can be accepted (contrary to hashing functions) as else the decrypted password would not be unique.

The main disadvantage I see is that the stored password length is correlated to actual password length, giving a clue on password strength. This can be mitigated by introducing a "lengthy" salt to the password, which will ensure that short password only look as short as the salt. Long password remain mostly unaffected but that is fine as they are long but might take space in the database.

Are there any other disadvantages to this technique?

I am guessing this has already been studied but I didn't find the name of such strategy.

TL;DR

The disadvantage you mention is less relevant than you think.
The bigger disadvantage to Asymmetric Encryption is that it's quite a bit cheaper than a properly configured Slow Password Hash.

So, you should use a Slow Password Hash. (i.e. BCrypt)

Theoretically, using an Asymmetric encryption routine (where the Private Key is permanently forgotten) is a reasonably secure one-way hash function, but this is not suitable for low-entropy input data (i.e. passwords)

  Asymmetric cryptography is usually more expensive than hashing and should therefore require less stretching for the same benefits.

I see that you understand the importance of an expensive hash routine to prevent Brute Force. While Asymmetric Encryption is slower than General Purpose Hash functions (i.e. SHA-2), what you should be using is a Slow Hash function (i.e. BCrypt) which is more expensive than either of the two aforementioned options.

  Stronger guarantee on the entered password: there is one and only one password which can be accepted. That is, no collision can be
  accepted (contrary to hashing functions) as else the decrypted
  password would not be unique.

Modern hash functions have a large enough name-space that collision is not likely to occur in the application's lifetime. Trying to find something even more collision-resistant is pointless.

  The main disadvantage I see is that the stored password length is
  correlated to actual password length, giving a clue on password
  strength. This can be mitigated by introducing a "lengthy" salt to the
  password, which will ensure that short password only look as short as
  the salt. Long password remain mostly unaffected but that is fine as
  they are long but might take space in the database.

The attacker would be able to see how many blocks long the encrypted password may be, but they would not be able to tell any more specifically than that. The vast majority of passwords can be stored in a single block (assuming a strong key size like RSA 1024 or RSA 2048) so this clue would be of limited use to an attacker.

  Are there any other disadvantages to this technique?

Asymmetric Cryptography is less expensive than a Slow Password Hash routine such as BCrypt.
Disk space requirements are higher.
"Don't roll your own."

There you have it, you should be using a Slow Password Hash such as

BCrypt, but be sure to run a quick SHA-2 hash on the input data, so super-long passwords will not be truncated by BCrypt
PBKDF2 but that is less GPU-resistant
SCrypt is better than BCrypt if you have a high enough work factor. Otherwise it is worse against GPUs.
The winner of the Password Hashing Competition may be even better than the aforementioned, but has not yet stood the test of time, so don't use it just yet. It's called Argon2, and has separate Work Factor settings for CPU time and Memory load. (nice!)

Most of these options generate random Salt by default, but do verify whether this is the case!

It is best to include some Pepper (~72 bits of entropy) before the Password prior to hashing. The Pepper can be the same for all your users, but should be stored in a file outside of the database so that component cannot be found via SQL Injection.

Make sure your Work Factor requires about 100ms (with appropriate DoS protection) on your target hardware (knowing that attackers will use faster hardware for Brute force)


How to determine all public IP adresses from within an organization? I can determine a single public IP address from within the organization (using NAT) by sending a HTTP request to one of the publically available services:

curl ipinfo.io/ip

However, if my request always takes the same route, then I will always get the same answer, even thus the organization might have several public IP adresses.

How can I enumerate all public IP adresses?

This is not possible.

As you mention, you will have a route (or a few) to get out of your network and you can see the outbound public IP address for there.

This may be only one of the many addresses allocated to a company. In particular, this outbound IP address may not be the one you would use to access publicly facing services (in a larger company this is very likely).

The non technical way could be via an ARIN / WHOIS search. The information you will find in there is as up to date as the network admins made it to be.

Then you can try to check the services you know about (www, ftp, ...) and may find an IP address which may or may not be one your company is an owner of (the web site may be hosted elsewhere for instance)

Except for asking the network admins there is not reliable way.


Can NSA generate all hashes for rainbow table to break md5? I was wondering about md5 encryption. It is good, and I agree that it is unbreakable.

But this is why we have rainbow tables.

What if bunch of people gather together and start brute forcing and creating a hash for every single possible combination of characters. Especially if you are someone like NSA then you probably have computational power to generate hash tables for all possible combinations within relatively "short" time. Therefore wouldn't that render md5 encryption pointless?

Sorry if this is inadequate question, but I simply couldn't stop thinking about this.

First of all, MD5 is not an encryption algorithm.  It is a hash function.  Encryption generally implies decryption, which you cannot do with a hash function.

Who said MD5 is good or unbreakable?  It is 'breakable'.  The complexity of obtaining a collision for MD5 is around 2^64.  This is the equivalent of an exhaustive key search of 64 bits, quite weak for modern cryptosystems.

Another aspect you need to know is you dont need to know the hash of every possible plaintext, but only the first collision they obtain. If A and B for example hashed give the same value, you would only need to store one of them.

MD5 is no longer used in 'reliable' systems.  Unix passwords for example stopped being hashed using MD5 quite a long time ago. Now they use SHA-512 (equivalent of a 256 symmetric key).


How to prevent host header attack in Ubuntu Server 14.04? If we send a request from any host like example.com our server gives back a HTTP 1.1 200 OK response status.

In correct condition it should show either 302, 400 or 404 error message (not found response) status. At current condition it is showing 200 OK response message, when its send through our host like xx.xxx.xx.xx.

For example, if we sent this request:

GET /web/ HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Connection: close
Upgrade-Insecure-Requests: 1

We get this response:

HTTP/1.1 200 OK
Date: Thu, 02 Mar 2017 15:23:20 GMT
Server: figi_Server
X-Frame-Options: deny
Strict-Transport-Security: 1
Vary: Accept-Encoding
X-Content-Type-Options: nosniff
X-Frame-Options: sameorigin
X-XSS-Protection: 1; mode=block

Note:

OS: Ubuntu 14.04.
Web server: Apache 2.2.
Virtual machine running both.

First, this is not an attack against your server because no harm is done on the server. And, it is not specific to Ubuntu Server version whatever but is specific to the web server and its configuration, i.e. in your case nginx with unknown configuration.

By default the web server has no idea which names are valid for your system. You have to explicitly configure which names are valid and what the server should do if no host header was given or none of the configured host headers was given. With nginx as used on your system this means to configure virtual hosts for all the names you want to accept, configure a default server to reject all requests to unknown names and maybe configure a similar server in case you want to specifically deal with empty host names.
For more details see the nginx documentation, specifically the part about "How to prevent processing requests with undefined server names".


Unable to get rid of Sality on my Dropbox The story...

As a group of rookie security researchers  who deal with malwares, viruses etc., me and my team-mates sometimes do commit mistakes in handling the binaries. And so, I ended up infecting my own pen drive with one of the malware binaries I was dealing with- Sality.

Without realizing that my pen drive is infected, I used it in my own system.
Fortunately enough, my Anti-virus could catch the infection. And I thought I was safe.
But today morning I saw my AV Avast crying loudly about Sality infections....that too, oddly enough, in my Dropbox's .dropbox.cache folder.

For those who do not know about the .dropopx.cache folder, please have a look here.

What I tried...

I have tried a lot of things to get rid of the infection or to get rid of the files themselves. First, I scanned the infected folder with my AV and got rid of the files. But they came back when Dropbox re-synced.

Next, I did a full system scan with Kaspersky's Sality killer and removed the infected files. But they were again back when Dropbox re-synced, and again my AV started crying.

shift+DELing the files doesn't help too, since they will still come back when I re-sync. I know this should not be happening as per the link I gave above, but it does happen!.

An important point to note here that our entire group uses Dropbox to share stuff amongst each other. So there is a possibility that someone else amongst us also got there system infected, and that is why cleaning my system is not helping me. But the fact that the cache folder has the infection makes me feel that infection is from my own system (not very sure here though...)

A snapshot of Avast's logs, for your convenience:

The simple question...

What on earth should I do now?? The whole purose of keeping all my work in Dropbox was to keep it safe from system failures etc. If that itself has caught infection, I am doooooomed :(

p.s: I cannot possibly nuke it from orbit...else my Supervisor will nuke me!!!

You're not doomed, everything is gonna be okay.

Pause Dropbox sync on all of the devices associated with this account.
Turn off all of the devices that have Dropbox installed and associated with that account, and any other device that you know/suspect they're infected.
Now that you know your files are okay on Dropbox, nuke all of the systems you've just turned off.
On a machine that you 99.9% trust its integrity, install the Anti-Virus product capable of detecting/cleaning Sality out of executable files.
On that machine, install Dropbox and associate it with your account. Watch as your Anti-Virus detect/clean the virus from the files.
If there were no infections, you're done. If there were infections and the Anti-Virus wasn't able to clean them, wait until all the files are synced and then reboot in safe mode and use Win32/Sality Remover (from AVG) and  SalityKiller (from Kaspersky) to do a final sweeping.

A coupe of notes:

Infected files on your Dropbox will not magically infect your new clean system unless you run them somehow.
If you have the option, it's better to restore all your files to a previous version using Dropbox website instead of syncing and cleaning. (it all depends on the age of your infection and whether you have Dropbox Packrat activated)


Config Server Firewall: What Outgoing ports need to be open for wget and apt-get install? I am just configuring CSF and I have to specify my outbound ports here. I am trying to close as many as possible leaving only what I need open, however what do I need to leave open for wget?

# Allow outgoing TCP ports
TCP_OUT = "20,21,22,25,53,80,110,113,443"

# Allow incoming UDP ports
UDP_IN = ""

# Allow outgoing UDP ports
# To allow outgoing traceroute add 33434:33523 to this list
UDP_OUT = "20,21,53,113,123

Firebind can test any outbound UDP or TCP port to tell you whether it's blocked or not, and if so, how it's blocked (DROP, RESET, etc.)

http://scanme.firebind.com/applet.html

You can test any of the 65535 UDP or TCP ports, or even the entire range.  They also have a bunch of preconfigured tests for popular apps and games.


Is it possible to lock down the http / https proxy settings on an iPhone? Is there any way to lock down the proxy settings on an iPhone so that they can't be changed by anyone but the person with the password?

Configuration 2 has an option specifically for a HTTP Global Proxy. You will need to get it on the Mac app store (https://itunes.apple.com/us/app/apple-configurator-2/id1037126344?mt=12).

Once you've downloaded that, create a new profile with the HTTP Global Proxy, sign it, and add it to your iDevice.

See this link for more information https://discussions.apple.com/thread/4359121?tstart=0


updatedb and encrypted home folders: Does it store unencrypted file and folder names somewhere? When you encrypt your home folder in Ubuntu and Debian, it protects not only the file contents but also the file and folder names.

Yet I see that updatedb and locate works in Debian. When I run locate, it finds files that are in my encrypted home folder. Does updatedb store the unencrypted file and folder names of your home folder somewhere?

The location of the database is  /var/lib/mlocate/mlocate.db or at /var/cache/locate/locatedb. This is outside your home folder. Probably you decrypted your homefolder prior to running the command and the results got saved in a non-encrypted folder.


Storing SSL certificates in DNS records Why not get rid of all certificate authorities and all the special kind of SSL certificates there are (extended validation etc. etc.) and instead just require anyone who wanted SSL to write their own self signed SSL certificate and then have them stored in DNS records.

Wouldn't that be easier then having to put trust in both 3rd party certificate authorities and in DNSSEC? Also then you could remove those security warnings given by browsers when using self signed certificates, I mean as long as your DNS wasn't poisoned then there wouldn't be a problem, also you have a huge number of choices when it comes to DNS providers which you don't have when it comes to certificate authorities trusted by common browsers.

Why not get rid of all certificate authorities and all the special kind of SSL certificates there are (extended validation etc. etc.) and instead just require anyone who wanted SSL to write their own self signed SSL certificate and then have them stored in DNS records.

There is even a standard for this: DANE. And it is already in use with some sites, but currently mainly for SMTPS and not HTTPS.

But, it needs DNSSec to make sure that DNS lookups are not spoofed. Because otherwise a man-in-the-middle attacker could simply send its own certificate inside the DNS lookup. Unfortunately DNSSec is not widely used at the moment, so for now we have to live with the established PKI structure.

But once DNSSec is deployed deep enough DANE is a promising technology and you can use it to either use your own self-signed certificates or to have an additional trust path with the traditional CA based certificates.


Is there any security reason for re-directing to the main/mobile page after login? Scenario: User searches for something and gets a link to a sub-page on a site, proceeds to go there, but is asked to sign-up/login - they do so, only then once they are logged in, they are redirected to the main page or the "mobile" version of the page, as opposed to the one that they were originally intending to view

Is there any sort of security reason for this, or is it just lazy programming, or something else?

This practice of resuming the original request after authentication is sometimes called "bookmarking," because it allows users to bookmark specific parts of a site and "go there" by way of the login process.

When bookmarking isn't available, it's usually a sign that the site wasn't designed or architected to allow it.  For example, if authentication is detected and enforced by a border device (like a Web Application Firewall), then the redirection to the login page may take place there, leaving the back-end application without any indication of what the initial target was.

In this case it would be a security-related decision - it is the imposition of the WAF that restricts the choices of the application.  Similar limitations can also occur solely within the application, if it isn't designed to maintain that state through the login process, in which case it wouldn't be a security-related limitation.


TrueCrypt vs BitLocker I would like to ask which one of these TrueCrypt or BitLocker is safer to implement and encrypt the data in a small business environment (Windows 7, 8.1 and Windows Server 2012r)

I read about BitLocker and I am confused. Many IT professionals recommend using BitLocker however I read as well that BitLocker has an industry (Microsoft) backdoor implemented.

Not sure about TrueCrypt. Is there a backdoor or is TrueCrypt vulnerable and safe to use for business purposes?

I am more concerned about cyber criminals rather than IT Law enforcements.

Edit: October 3, 2015 An article in IT World for September 29, 2015 reveals the existence of, but doesn't describe fully, two serious flaws in the Windows driver that TrueCrypt installed.  It isn't clear from the article whether those flaws compromise the crypto or the underlying Windows OS, or both.  It also isn't clear whether that driver is installed only for full-disk encryption or at any time a TrueCrypt volume is in use.

Original answer below:

It is unknown (except probably to Microsoft and the NSA) whether BitLocker has a back door.  You cannot examine the source code to find out, either.  (And even if you could, a purposeful weakness might be very difficult to spot, even for an experienced cryptographer.)

TrueCrypt's source code is available and has (as of today) been audited.  No back doors or purposeful weaknesses were found.  So, speaking only in terms of back doors, TrueCrypt (the version before last) is "safer" because it can be and has been examined by experts.

Test it on Windows 10 before you commit because TrueCrypt is no longer supported by the original authors.


How to find full geo location of computer from IP address? I lost my computer and I need to find it. I know IP address of computer. How to find location of computer from IP address?

Thank you in advance.

Check out https://www.iplocation.net/

Plug in the IP and you are good to go.

Do note there is a difference with public and private IP. 192.168.1.1 will not find you anything


Storing personal information in cookies I'm trying to do a simple display integration between two websites.

One on:

domain.com

and another on:

subdomain.domain.com

All I want to do is show a "Hello John, Return to Client Area" message.

I'm looking for some advice on whether you think it's acceptable to store information such as a first name and e-mail address in a cookie?

I need first name for "Hello [Name]" and email for a gravatar. I could pre md5 the gravatar, or add the gravatar url to the cookie, however its a similar premise either way.

This information will be useless, so changing it won't be able to do anything malicious.

I know i could simply create a [logged in = true] cookie that shows return to user area. However i feel the other way gives a better illustration of being logged in.

First of all, I hope by domain.com and subdomain.domain.com you do not mean you are using HTTP in which case the cookies are highly exposed and manipulated on an attacker's will. I hope also -in case you are not using HTTPS- the services of your website are not crucial (not e-commercial, for instance).

As a general good security practice, **never store private information in cookies **. If a client of your website uses his/her main email address to login then for sure they wouldn't like to see it used by a third party (spams) thanks to your website (in case you use, for example, Google AdSence). Add to this a set of common famous cookies' vulnerabilities such as  cross-site cooking or simply cookie theft.  An email address is important data -in my case, I wrote it encoded on my profile. I definitely advise you not to use email within cookies.

Solution:

As everything else, sessions are not safe for 100%, but still it is better to generated unique session identifier in the cookie, and  store everything else on your server instead. This pretty much eliminates common threats such as cookie poisoning. And as for cookies, do not store  any data in the session pertaining to access credentials (in your case, the client's email ?)


Is there any way or tool to check whether a particular iOS app is implementing SSL Pinning functionality? I'm just learning the iOS security. This is completely a beginner question.

I'm trying to figure out whether there is any particular way to check if an iOS app is implementing SSL Pinning functionality.

I've currently checked the SSL traffic of some apps over Burp Proxy. Even after installing Burp Proxy Certificate, some apps are throwing some Alerts, such that there is a fatal error, so the client failed to negotiate an SSL Connection. And I'm not sure whether it is the appropriate way or not.

But what is the exact and perfect way to figure it out ?

Thanks in Advance

Using Burp is a good way to test it. But don't forget to import Burp's CA certificate on the device so that it is trusted by the device. Visit http://burp in the device's browser and download and install the certificate.

Most apps will now work over SSL and you can see their traffic in Burp. But apps that still fail are doing more checks, i.e. 'pinning'.

You can do the same using mitmproxy. In that case, visit mitm.it in the browser to import mitmproxy's CA certificate into your device.

Edit
It occurred to me that in Burp, you are not seeing the failed connections that the apps tried to make - you will only see successful ones. What I use to solve that is a tool called mitmdump, which is like a basic version of mitmproxy (mitdump comes with mitmproxy). It will not only show successful connections but also what SSL connections were refused by the client, so you will know what the app tried to do, and you can see that it was the app that refused to go any further.


What are the disadvantages of using public key cryptography when encrypting files? I am wanting to encrypt a file with my public key, my friend told me that this is not a good idea but did not explain why. Can someone explain please.

Your friend is correct in that private key encryption is not the tool for the job. This answer on Cryptography.SE does a good job of explaining why. Some highlights:

  Any public-key encryption schemes is bound to increase the size of the data that it enciphers.

  While there are more efficient schemes, it is safe to say that a symmetric scheme is orders of magnitude faster and less power hungry than an asymmetric one, at least for decryption.

Private key cryptography is used when the person doing the encryption is different from the person doing the decryption - a situation symmetric cryptography can not handle if the parties can not easily exchange keys.

When private key cryptography is used for transfering larger volumes of data (like in TLS), you normally first encrypt the data with a random symmetric key. Then you encrypt the symmetric key with the recievers public key so that they and nobody else will be able to read it and decrypt the data.


What are the advantages of EV Certificate? What are the various advantages of using extended validation (EV) certificates than normal certificates which also provide comparatively high degree of encryption like RC4, 128 Bit?

I know that the browser shows green flag for EV certs. But is there any other benefit than just that?

Extended Validation certificates are intended to show the user more visibly the institution to which they were issued. The technical aspects of the certificates themselves is combined with visual clues in the user interface of the application verifying them: the green bar and a visible name next to the location bar in the browser.

For example, the EV certificate at http://www.paypal.com/ will make the browser show a green bar and display "PayPal, Inc." next to it. This is designed not only to link the certificate to the domain owner (like standard domain-validated certificates do), but also link it to a more physical institution (here, PayPal, Inc.). To do this, the CA must verify that the named institution is indeed the one owning the domain.

Ultimately, this is more about making a more authenticated link between the domain name and the company name than making "more secure" certificates. From a cipher suite point of view (which is what determines the encryption algorithm and key size), EV certificates are no different from DV certificates (blue bar).

Stepping back a little, you need to realise that the effectiveness of HTTPS relies on the user checking that it's used correctly. (The server has no way to find out whether the client is victim of a MITM attack otherwise, unless using client-certificates too.) This means that the users have to:

check that HTTPS is used when they expect it to be,
check that there are no warnings,
check that the website they're using is indeed the one they're intending to visit, which leads to a couple of sub-points:

checking that it's the domain name they expect,
checking that the domain name belongs to the company they expect.

EV certificates are intended to solve that last sub-point. If you already know that amazon.com belongs to Amazon.com, Inc. or that google.com belongs to Google Inc., you don't really need them.

I'm not personally convinced that this approach completely works, since they can be misused (see NatWest/RBS example below) and some CAs seem to propagate vague (and potentially misleading) information as to what they really are, in an effort to promote them.

In general, if your users already know that your domain name is yours, you don't really need one.

Here are more details from a previous answer I gave to a similar question:

  [...]

  The domain-validated certificates guarantee you that the certificate
  was issued to the owner of that domain. No more, but no less (I'm
  assuming the validation procedure was correct here). In many cases,
  this is sufficient. It all depends on whether the website you are
  promoting needs to be linked to an institution that is already well
  known off-line. Certificates that are validated against an
  organisation (OV and EV certs) are mainly useful when you need to tie
  the domain to a physical organisation too.

  For example, it's useful for a institution that was initially known
  via its building (e.g. Bank of America) to be able to say that a
  certificate for bankofamerica.com is indeed for the place where you've
  given your physical money. In this case, it makes sense to use an OV
  or EV certificate. This can also be useful is there is ambiguity
  regarding which institution is behind the domain name (e.g. apple.com
  and apple.co.uk), which is even more important is the similar domain
  name is owned by a rival/attacker using the name similarity for bad
  purposes.

  In contrast, www.google.com is what defines Google to the public;
  Google has no need to prove that google.com belongs to the real
  Google. As a result, it's using a domain-validated certificate (same
  for amazon.com).

  Again, this is really useful if the user knows how to check this.
  Browsers don't really help here. Firefox just says "which is run by
  (unknown)" if you want more details about the cert at www.google.com,
  without really saying what is meant by this.

  Extended-validation certificates are an attempt to improve this, by
  making the organisation-validation procedure more strict, and by
  making the result more visible: green bar and more visible
  organisation.

  Unfortunately, this is sometimes used in a way that increases
  confusion, I think. Here is an example that you can check by yourself:
  one of the large UK banks (NatWest) uses the https://www.nwolb.com/
  for its on-line banking services. It's far from obvious that the
  domain name belongs to NatWest (who also own the more logical
  natwest.co.uk name, by the way). Worse, the extended validation (if
  you check the name next to the green bar) is done against "Royal Bank
  of Scotland Group plc".

  For those who follow financial news, it makes sense because both RBS
  and NatWest belong to the same group, but technically, RBS and NatWest
  are competitors (and both have branches on the high street in the UK
  -- although that's going to change). If your user doesn't have that extra knowledge about which groups trade under which name, the fact
  that a certificate is issued to the name of a potential competitor
  should ring alarm bells. If, as a user, you saw a certificate on
  gooooogle.com issued to Microsoft or Yahoo, however green the bar is,
  you should not treat this as Google's site.

  One point to bear in mind with EV certificates is that their
  configuration is hard-coded into the browsers. This is a compile-time
  setting, which cannot be configured later on (unlike normal trusted
  certificate stores, where you could add your own institutional CA
  cert, for example). From a more cynical point of view, some could
  consider this as a convenient way for the main players to keep a
  strong position in the market.


How does Glassdoor know what my password is... on other, unrelated websites? I just tried logging into Glassdoor and recieved this message:

  We have temporarily disabled your account. We have identified that your password matches one you have used on an unrelated website that has experienced a security breach.

I checked here and the only breach I was a part of was the "Hack Forums" breach—a forum where my password was totally different than the ones I regularly use because... it's hack forums, and I didn't trust it.

Is something fishy going on here? How would Glassdoor even know this?

I see three possibilities:

Glassdoor knows about a breach that haveibeenpwned.com doesn't know about.
Glassdoor isn't telling the truth. Perhaps they have only found your email in a breach, and not your password. Could be an honest mistake, or perhaps they want it to sound more serious and urgent to justify the extra work they force you to do.
Your memory is wrong, and you did in fact use the same password at some point in time (not necessarily now).

Only way to find out which one is to ask Glassdoor.


OBKG on smartcard with PKCS#11 I have a new  smart card with an on board PKCS#11 module and operate in a Win 8  environment. Like many cards, it can generate its own key pairs for enhanced security (only the public key can leave the card). The keys generated are not OTP keys, they are stored directly into one of the available PKCS#11 slots.

In particular, I would like to use such keys for ssh/putty connections. I have tried a number of smart-card enabled Putty clones as well as Salt. At no point am I offered the possibility to use any of the OBKG key pairs I had the card generate.  However, all are able to present keys stored on the card imported via preexisting .p12 bundles.

Question: What is necessary for programs and OS to access card generated key structures, or more simply, know that they exist and are available for use? [not asking how to pull a private key out, that should never be allowed]

For completeness, the card in question is a Gemalto IDPrime 3810 which is not PKCS#15 compatible and uses a Gemalto mini-driver and pkcs#11 dll.

Accessing OBKG keys is possible in the general sense (ie, with other smart cards/tokens) and specifically this comment from a Gemalto user. Not much point to having the ablity to generate these keys if there is no way to extract/use them.

For those looking on how to make use of the OBKG function on some Gemalto smart cards with SSH, I wrote up my experience here   I'm sure someone with more knowledge could automate the process (or knows a better way) but mine did work out in the end.


Strange responses from an unfamiliar HTTP server I noticed an unfamiliar device when scanning my local wireless network. It had two open (listening?) TCP ports; TCP/80 (http?) & TCP/443 (https?).

In an effort to identify the unfamiliar device; I exercised some basic banner-grabbing techniques, which provided some strange feedback:

root@localhost:~# telnet 10.1.1.28 80
Trying 10.1.1.28...
Connected to 10.1.1.28.
Escape character is '^]'.
HEAD / HTTP/1.1
@Q�0�njs-k��`Y���s��N��E2R�S������d���aw��
s�Y�/u"�`QN���I�eRA~W

Connection closed by foreign host.

- - -

root@localhost:~# telnet 10.1.1.28 80
Trying 10.1.1.28...
Connected to 10.1.1.28.
Escape character is '^]'.
GET / HTTP/1.1

HTTP/1.0 404 Not Found

Connection closed by foreign host.

- - -

root@localhost:~# telnet 10.1.1.28 80
Trying 10.1.1.28...
Connected to 10.1.1.28.
Escape character is '^]'.
HEAD / HTTP/1.1
"�))!���]D�7�ב�����┴�IL&�┬��#�-�zp�,o�������c��D����ל]�h����
                                                                @�.GLMC��2{���

Connection closed by foreign host.

What are these strange responses?
What do they mean?

If you insist on talking HTTP through telnet, a proper HTTP server won't answer you before you're sent two consecutive line feeds, effectively ending your request:

GET / HTTP/1.0
<empty line>

If the service starts answering you before sending the empty line, it's not speaking proper HTTP, and may be something else entirely. I'd suggest using a tool like cURL to ensure proper use of protocol. Here's an example:

[root@vostok ~]# curl --dump-header - --silent http://127.0.0.1/
HTTP/1.1 404
Server: nginx
Date: Wed, 11 May 2016 07:16:15 GMT
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Expires: Sat, 26 Jul 1997 05:00:00 GMT
Last-Modified: Wed, 11 May 2016 07:16:15 GMT
Cache-Control: no-store, no-cache, must-revalidate
Cache-Control: post-check=0, pre-check=0
Pragma: no-cache

It may also be a HTTPS service listening on a non-standard port (like port 80, the standard HTTP port). Try the above cURL command with protocol and port explicitly specified in the URL like this: https://127.0.0.1:80/

It may not be HTTP or HTTPS at all, but some other SSL-enabled service. If you want to probe that, you could use OpenSSL to open an SSL-enabled telnet-like connection:

openssl s_client -host 127.0.0.1 -port 443

If it is indeed SSL-enabled, you'll get all sorts of information, including details about the certificate used.

Good hunting! :-)


Are there attacks to steal database records from memory in cloud? Imagine a hosted database in public cloud. The database records are encrypted only on disk (data-at-rest). Are there are any attacks that steal the database records from the memory (when queries are being executed etc? )?

Especially am looking for threat vectors opened up due to virtualization and cloud. I read about RAM Scraping etc on POS Terminals but not sure if there are attacks feasible on a remote virtual machines in cloud

Stealing data living on one VM directly from another VM is not a realistic attack scenario currently. While there are side channels which allow a small information leakage it is currently more a theoretical and expensive thing to exfiltrate data that way.

Much more likely are attacks directly against the VM containing the data (i.e. SQL injection, SSH brute force....). There is nothing special VM or cloud related with these attacks, i.e. once you have system privileges or even kernel privileges you can access the memory of any process.

Less likely but still realistic are attacks against the hypervisor, like breaking out of a neighbor VM or attacking the system where the hypervisor runs on. Once you got system or kernel privileges on the hypervisor this way you get full access to all VM's in control of the hypervisor. This includes full access to the memory of these VM.


Can someone listen GSM calls with RTL-SDR dongle if A5/1 cryptography is successfully cracked? Can an attacker listen GSM calls in clear audio form (real time) using RTL-SDR dongle if he/she has powerful-enough hardware to crack the A5/1 crypto scheme in countries where no more secure cryptography is used by mobile operators for encrypting the conversations?

How easy this can be done?

Short answer: Yes - but it needs work.

Some background: If - as you assume - A5/1 is cracked, than the attack scenario is the same as using no encryption at all.  Karsten Nohl showed in 2010 that if you have the key Kc, you can decode a GSM phone call.

Open Points or things that must be done:

Currently only the downlink channel was attacked (this is the communication from the base station to the phone).  This signal can be traced in the whole cell.  Uplink traffic (communication from the phone to the cell) is somewhat harder to trace (e.g. no synchronization logical channel like the FCCH in the downlink, weak signal).
Base stations are allowed to use channel hopping, i.e. the traffic is transmitted over multiple physical frequencies.  Because it is IMHO not possible to switch the frequency of the RTL SDR in that short period of time, you need typically more than one device to listen to all physical frequencies at once.  So, if the cell has three hopping channels, you need six devices: three for downlink and three for uplink.
Synchronization of these devices must be done: on the 'analog' side the frequency offset (evaluation of the FCCH) and on the digital the synchronizations of the frames of different frequencies.  IMHO there is currently no free and open source software available handling these kind of things.
If you want decoding in real time, there is also some work needed.  Software like airprobe can be used for tracing calls, but it's used more like a batch job (collecting data and afterwards processing).

(Please note that the answer is only about GSM. In 3G (UMTS) or 4G (LTE) it's completely different.)


password grant without client secret? I'm struggling to decide what to do to get an access token from a mobile app.

I'm sure this has been covered before, but I can't find it.

I've enabled resource owner credentials grant on my oauth2 server. The grant requires client id, secret, and a user's username and password.

If I don't want to store my client secret in my mobile app, is it safe to send ONLY client id and issue an access token if client id value stored in the user record matches the client id sent from a mobile app?

What's the best practice for this use case?

There are multiple problems with what you are trying to do...

General Information

OAuth2 in the "traditional" way is not meant to be used on anything other than a webbrowser. This means that if you have a desktop application or a mobile application, you should not use "traditional" OAuth2 for authentication. By "traditional", I mean the one where you get redirected to the provider website to enter your username/password then redirected back with a token that will be used by the client and etc.

Now let's start the explanation... OAuth2 documentation can be a bit confusing at first. What they refer to as a client is what we usually refer to as server when we are developing web application. There is 3 part to OAuth2 :

Service Provider : Google, Facebook, etc.
Client (webserver, desktop application, mobile application communicating with the service provider)
User (the application the physical user is using)

The problem with mobile and desktop application is that the client and the user is the same thing AND they reside on the client machine. Ever heard the saying "there is no security client side"? This pretty much apply here.

Problem 1 : The client secret

You are right to not want to put your client secret in the mobile app because your app can be "decompile" and hacker will retrieve your client secret. Once they have it, they can create their own application and impersonate your app.

Problem 2 : Username / Password

Don't use the "traditional" OAuth2 on a mobile/desktop application. The problem here is how you enter the username/password and how you retrieve the token that the service provider give the user after he logs in. Let's look at possible way to get it "working securely"...

Fail attempt 1 : Ask your user to enter username/password directly through your interface.
Reason for being bad : Congratulation, you just stole the facebook login of all your users.

Fail attempt 2 : Open a browser with the provider page.
Reason for being bad : How do you get the token back from the browser now? There is no way to get it (unless you have a malicious application constantly reading what is in the browser of the user)

Fail attempt 3 : Open a fake browser to lure the user to give you it's log in information.
Reason for being bad : Same at attempt #1. Mobile application can go full screen and control everything you see so you cannot trust them. Desktop application can open new window that could mimic your browser, etc.

The hard fact is that there is no way to make "traditional" OAuth2 work without a secure webbrowser that acts as the "user" and an https webserver that acts as the "client".

OAuth2 was never designed to provide authentication but rather just authorization. There is a big distinction between the two. OAuth2 protocol was "hacked" in order to make it able to provide authentication also (check OpenId). The only problem with this "hack" is that it only works in webbrowser like explained previously.

A real solution

If you still want to continue using OAuth2/OpenID for your login and wanna do it in a secure way, it will be a bit different than what you have imagined. Using OAuth2 for login is still a good idea as it saves your users the trouble of remembering yet another username/password.

You will need a server where your client id and secret will be stored. Your mobile app will connect to this server to send the token.
When ask for log in, redirect the user to the service provider webpage in a browser. Alternatively, the user could go directly to your https website to log in which will again redirect them. The service provider webpage is the only place your should enter your log in information.
Create an https webpage where the user will be able to see the token once he logs in using the service provider.
Ask the user to copy this token into your application. Your application then send the token to your server. The server add the client id and client secret and forward it to the service provider.

Your user can now use their "facebook" login to log into your application and there is no way for your application to steal their log in information or for an hacker to steal your client secret.

Additional Note

The case of phishing attacks and OAuth2 when used outside a web browser is an interesting one as well but that would be the subject of another question.


Main difference between Yahalom and Needham-Schroeder key exchange protocols I am just wondering what is the main difference between the Yahalom and Needham-Schroeder key exchange protocols?  Which protocol uses less computational power?

I have added a table which can be useful. From the number of encryption and decryption operations, decide for yourself which one is computationally expensive from a client and key server perspective. A, B are clients and S is the key server.


Guessing the whole PBDKF2 output from 1 half If I use PBDKF2 with a good enough password and salt to generate a 2n bytes key, does knowing the first or last n bytes make it any easier for a 3rd party to guess the other half of my key than using a brute force attack?

PBKDF2 is supposed to be secure as a key derivation function, which more or less means that knowing some of the output bytes leaves no usable information for guessing the other output bytes. If you produce 20 bytes with PBKDF2 but the attacker knows 12 of them, he still cannot guess the 8 remaining with better probability than pure luck (i.e. 2-64, since 8 bytes is 64 bits).

Note, though, that the "P" in PBKDF2 means "password", and the main weakness of anything involving passwords is that passwords are, in practice, guessable through dictionary attacks. While having a partial output does not yield immediate information on the other output bytes, it can serve as a fast test for a brutal enumeration of possible passwords.

A "normal" dictionary attack on PBKDF2 assumes a situation where the password was expanded into a symmetric encryption key, used to encrypt a piece of data. The attacker "tries" passwords, each time computing the corresponding key, then trying to decrypt the data, and see if the result "makes sense". If the attacker knows some of the bytes produced by PBKDF2, then he can skip the "decryption makes sense" step, which helps him a bit.


Security issues in "Remember Me" function code example I'm a beginner, and these may be very obvious for you, but I'm trying to understand if there are security issues with this example.

Today on Stack Overflow, I saw the following post: PHP Sessions Login with remember me.

The question is about creating a "Remember Me" function to extend the authenicated session for logged-in people.

The accepted answer was:

function setSession($username,$password,$cookie=null){
    // Other code for login ($_POST[]....)
    // $row is result of your sql query
    $values = array($username,$this->obscure($password),$row['id']);
    $session = implode(",",$values);

    // check if cookie is enable for login
    if($cookie=='on'){
        setcookie("your_cookie_name", $session, time()+60*60*24*100,'/');
    } else {
        $_SESSION["your_session_name"] = $session;
    }
}

So, my question is not about how you should do this, but am I correct in the security issues I outlined below for this code example?

Using the OWASP Top 10 for reference, these are the issues I see:

Issue 1 :
First we can suppose that $session has the password and the username because the $value contains the username and password of the user. Also with this line:

setcookie("your_cookie_name", $session, time()+60*60*24*100,'/');

The cookie has now the credentials of the user. A big mistake for me, see Issue 3 for more.

Issue 2 :

I read this OWASP article where they say that to prevent CSRF we need to
generate a random ID associate to the SESSION or Cookie.

Obviously in this code there isn't a token or unique ID which is suspicious to me.

Issue 3 :
We can also imagine the site might be vulnerable to 'Cross-Site Scripting (XSS)'

In fact, if the credentials of the user are stored in a cookie we can execute a simple script and show the cookie.

alert(document.cookie);

Question

I'm sure there may be other issue, but I've exposed the most obvious for me.  Am I right in the issues I've identified? Did I miss  any other big security issues with this code?

Storing sensitive data in a cookie is not necessarily unsafe, it depends how you configure the cookie. Te cookie needs to be configured as a secure cookie (limited to HTTPS only), HttpOnly flag should be set to avoid cross side scripting (the cookie will not be available from javascript) and the domain must be set to the correct value depending on the scope of the cookie.
Using these settings it is OK to place the username in the cookie.

Regarding the other data in the cookie it is possible to create a triplet of username, series token and one time token.
This triplet is stored in the database and in the cookie and can be compared in order to authenticate the user. There is an excellent article explaining this technique on Barry Jaspan's blog

If you would like an additional security measure, you can further encrypt the cookie value with a key found on the server so the details such as the username and tokens cannot be read on the browser even by the user himself. But if you have a load balanced environment you will have to make sure the encryption key is shared between all instances using your DB for example.

Regarding the specific implementation mentioned in your code example there are a few concerns:

what does the obscure function do? even if its a one way has function it would be safer to just use a cryptographically secure pseudo-random number instead
what is the idea of the row id parameter? it is not understood and is not random
it is not clear what it means when $cookie is not 'on'. The authentication values are then stored in the session instead of in a cookie. If $cookie!='on' means that cookies are disabled, this is a bad practice, since session ID will be kept in the url.


Gnome-keyring iteration count location I know that Gnome-keyring hashes the master password between 1000 and 2000 times. It picks a random number. I would like to ask where it saves this number, what is the location of that file? As far as I know it needs this count number when decrypting the files with saved passwords.

According to my reading of the source code (docs/file-format.txt), the iteration count is stored in the keyring file, specifically in the 25th through 28th bytes after the end of the keyring name.


Why do law-abiding citizens need strong security? The layman's counter-argument I run in to for any complaint about inadequate security seems to always take the form:

  You don't need security if you aren't doing something illegal.

This kind of response is frustrating to say the least. In part because it's not constructive, but also because it's blatantly false.

How do you deal with these kinds of responses from people?

I'm looking for concrete examples that can be presented that show the need for strong security when conducting perfectly legitimate activities. Examples in the areas of trust worthy encryption on end-to-end communications for cellular networks, network identity obfuscation services like Tor or VPNs, complete and total data destruction, and so on are what I'm after.

I'm always inclined to point to social uprisings in states like Libya and Egypt but these events tend to be presented to too many of the people I encounter that use this argument as "things that happen on TV" and not real things that have any effect on them or their personal liberties. So counter-arguments that keep it squarely in the first world, it-could-hurt-you-or-your-grandma kind of are really valuable here.

  This question was IT Security Question of the Week.
  Read the Oct 10, 2011 blog entry for more details or submit your own Question of the Week.

You don't need to lock your front door unless you're a thief.

It's the same idea in all relevant respects.

Each person needs to take reasonable measures to protect himself and his property from those who would harm him or his property, in accordance with his best judgment of the risks.

You buy a lock and lock your front door if you live in a city, in close proximity to hundreds of thousands of others. There is a reason for that. And it's the same reason why you lock your Internet front door.


Is there any security benefit to be connected over HTTPS if certificate isn't valid? TL;DR: Is there any difference between an authentic and a secured website? More precisely, is there any security benefit to be connected to a website via HTTPS if the certificate isn't valid?

Following a test I had today where we was asked if it was better to be on a secured website or on an authentic website when browsing on a shopping website, I wondered if there was any difference between secured and authentic.

IMO, by definition, an authentic website has to be secured, otherwise any authentication of the website would be meaningless.

But then, is it true in the other way? Is a secured website necessarily authenticated? Can we still consider that you are using HTTPS and that there is a security benefit to it if the certificate isn't valid?

From my personal understanding, while a "non-authenticated asymmetrically secured connection" will be less secured than an authenticated one, there is still the benefit that as long as no man in the middle attack occurs, nobody will be able to decode what was transmitted, am I right?

Generally speaking, you are corrct.  You are still connecting via HTTPS, as you surmised. Authentication, however, is indeed a critical part of TLS and HTTPS security. Even though the data is protected by TLS, without a valid and correct certificate, you can't be certain who you're actually talking to on the other end.  It may be a server for the site you expect. It's very hard to know, however, if in fact there may be a man-in-the-middle instead, decrypting and examining (and possibly tampering with) the traffic in the clear before re-encypting it to forward back and forth between you and the site you think you're talking to.

So while there is a certainly a possibility that an unauthenticated connection might still be secure, it's quite difficult to know, and in most cases a certificate errors is indeed going to be an indication that something is amiss with the connection.