Is it possible to setup a phishing “honeypot” for proof-of-concept purposes without getting the host/IP blacklisted?

Lock the site to your target IP range and display a benign placeholder ("coming soon" or "it works" or even a 404 error) to any client outside that IP range. (This is the easiest way for real world phishing to prevent listing by crawlers and it is a pain to those of us that are trying to keep the world safe.)
This will not, however, prevent listing from phishing detectors that can draw conclusions without crawling your site (e.g. by the look of the URL or DNS metrics).


What would be a good way to send sensitive information to users that are not very tech-savvy?

Passwords are stored as one-way hashes if done correctly, so you can't send them those. And if you can, make it your top priority to not be able to do so. Password reset workflows through SSL are the way to do that.

For other sensitive data, I'd keep it simple and just require them to log into your system. If not knowing their password is what prevents this, then reset their password through a secure password reset workflow.


How does Let's Encrypt prevent imposters?

Although Let's Encrypt issues domain-validated certificates and these guarantee only that a certificate was requested by an entity owning the domain, it does have policies in place to prevent imposters in certain cases.

According to the stipulation "3.2.4.3 Verification against High Risk Certificate Requests" in "ISRG Certification Practice Statement"
(v1.4, May 5, 2016):

  To prevent potential phishing, fraudulent use and to take further precautions against potential compromise,
  The CA maintains a list of prior high risk requests and checks a third-party authority list specifying current
  high risk Domain Names. This list is used by servers to identify potential risks. Should an application with
  any potential risk posed to the CA or a Domain Name listed on the third-party authority list, it will be
  flagged and brought to the attention of management to complete further internal verification. To prevent
  high-risk Issuance of a DV-SSL Certificate this internal verification will require one or more the following
  pieces of evidence:

  Request further documentation confirming control of the domain from the Applicant;
  Careful examination of the FQDN to confirm whether the intent of the Domain Registrant or
  Applicant is to imitate or mislead customers of an FQDN on the high risk third party authority list
  in order to commit fraudulent or phishing activities (e.g. www.g00gle.com, www.1dentrust.com,
  etc.) and specific filters that are established at the system level to deny initial applications (e.g.,
  non-US ASCII characters);
  Manual review of all information provided in the online application form; and/or
  Other verifiable proof as deemed necessary by the CA management.

According to the above it is (very likely) not true that you could obtain a certificate for faceb00k.com.

Regardless of that, Let's Encrypt certificates have only the Common Name value set to a verified domain (e.g. CN=example.com), so you could never get a certificate from them with O=Facebook Inc., even for a domain not subject to the above verification process.


HSTS: Clicking through certificate errors

Your browser doesn't apply the HSTS policy of test.example.com because it hasn't seen the header before over error-free secure transport. Therefore, it still allows you to "add an exception".

  The user agent processing model [...] stipulates that a host is initially noted as a
     Known HSTS Host, or that updates are made to a Known HSTS Host's
     cached information, only if the UA receives the STS header field over
     a secure transport connection having no underlying secure transport
     errors or warnings.

(From RFC 6796, emphasis my own)

Seeing the header over plain HTTP or with certificate warnings doesn't count:

  The Strict-Transport-Security header is ignored by the browser when your site is accessed using HTTP; this is because an attacker may intercept HTTP connections and inject the header or remove it.  When your site is accessed over HTTPS with no certificate errors, the browser knows your site is HTTPS capable and will honor the Strict-Transport-Security header.

(From MDN)

Also, note that your includeSubDomains directive from www.example.com doesn't apply since test.example.com isn't a direct subdomain (doesn't match *.www.example.com).


Does Android encryption really prevent law enforcement access?

Disk encryption only protects your phone when it is turned off (i.e., it protects data at rest). Once the device is turned on, data is decrytped transparently, and (at least with the current implementation) the decryption key is available on memory.

While Android uses the device unlock PIN/password to derive the disk encryption key, the two are completely separate. The only way someone can change your disk encryption password is if there is a device administrator application installed that allows remote administration (or they have a hidden backdoor you don't know about, but in that case you are already owned). UPDATE: the Google account fallback has been removed in 5.0+.

The article you link seems to be rather old and out of date. In current Android versions, login with Google account is only supported as a fallback to the pattern unlock (not the PIN/password) one, so if you are using PIN/password you are generally OK. Again, this only works if the device is already on, if it is off, they will need the disk encryption password to turn it on (technically to mount the userdata partition).

That said, because the disk encryption password is the same as the unlock password, most people tend to use a simple PIN which is trivial to bruteforce with the current implementation (slightly harder on 4.4 which uses scrypt to derive keys). Android L seems to have improved on this by not deriving the disk encryption password directly from the lockscreen one, but no details are currently available (no source). It does seems that, at least on Nexus devices, the key is hardware-protected (likely TrustZone-based TEE), so bruteforcing should no longer be trivial. (Unless, of course, the TEE is compromised, which has been demonstrated a few times.)

BTW, turning encryption on also helps with factory reset, because even if some data is left on the flash, it will be encrypted and thus mostly useless.


Is there any publicly available information about how sqlmap works?

You may want to look at the list of presentations maintained by the sqlmap project.  For example, they list sqlmap - Under the Hood and link to the slides.  The same talk as presented by the author is available on Youtube (since slide decks often leave out the meat of the discussion).


What are the pitfalls of bypassing a proxy to access cloud services such as G Suite or Office 365?

The biggest security pitfall is visibility into a major egress window for data. Today we know that over half of all cyber attacks have to do with malicious files and emails, often being sent together in a phishing campaign. Proxies are a wonderful way to tackle parts of this problem.

By sending networked traffic through a proxy we can spot malware coming in and protected data exiting our network. In combination with DLP systems and malware/behavioral analytics network administrators can prevent many unwanted connections from occurring. Without this layer, any encrypted communication becomes unintelligible to the security team. This is not ideal.

Bringing this to Office 365 or GSuite. Both cloud systems are used to send and receive data in a variety of formats from files to emails. As a business, I would not want any of my IP, PII, PHI or other data being extracted through these services except under explicit permission. Likewise, I would not want one of these services to flow into my network as a covert attack channel if we remove the capability to read files coming from the cloud to the data center or end point.

Bypassing a proxy, without other sufficient data controls such as host based DLP or EDR could lead to a major hole in a corporate security net. All it takes is a docx with a malicious macro to start stealing data from your network. Even worse, if the attacker’s determines you can’t read traffic in and out to a cloud system, they will be encouraged knowing you may not detect the data leak at all.

This is not to say proxies are always required. However, they are a significant tool in the defense against data misuse or malware infiltration. Bypassing proxies without sufficient defense against data loss through a cloud service or the inability to track downloaded malware through those services may be a night mare.

In security, visibility can be everything.


Where is RSA Digital signature used in the online banking world?

There are several Digipass products; not all of them compute digital signatures with the meaning that cryptographers attach to this expression (i.e. RSA and its ilk). If your token is not plugged into the machine, but just generates a numeric code which you type in, then there is no RSA involved. This does not prevent some documentations from (ab)using the term "signature" in that case too (I blame Microsoft for that confusion).

PKCS#11 is an API which applications use to talk to cryptographic hardware: this API is implemented by the driver for the specific hardware you use. For a token which is not plugged in at all, then there is no hardware (from the point of view of the computer), hence no driver, hence no PKCS#11.


Detecting when a screenshot is taken by a software (spyware) in Windows

My answer would require writing some code. I'm only posting this answer because you mentioned a programming related solution in your question.

Ever since Window Vista, the windows kernel raises an event for basically every single thing that happens on your computer. Microsoft provides a library called TraceEvent for .NET that makes it absolutely trivial to hook into these events.

For detecting a screenshot, you could monitor memory write events, file write events and so on. You can also hook into notifications for socket IO and the like. You can do all of this in around 30 lines of code.

From there, depending on how invasive and thorough you want to be, you could do a number of things. You could hook calls in the unknown processes such as Winsock's send function, and wind up scraping a copy of all data that the process writes to a socket, and check it. You could look for a JPEG or PNG header in scraped data and fire off the alarm bells if you find one. You could open and analyze files it writes, etc.

It's at this point that things can get complicated, but you could probably hook the send function with a library like EasyHook with a hundred or so LOC.

Another approach would be look at what libraries/WinAPI functions such an application would need to load to perform this function. You can detect when a process starts and when it loads an assembly (.dll) with these kernel events, so you could just look for the right (or wrong) combination of loaded assemblies. You could automatically hook WinAPI or OpenGL or DirectX functions that provide screen capture capability in every process that starts up, and directly monitor when applications access these capabilities.

For more information about this general approach you can see my other answer here.

I'd like to make it clear that the only thing I'm advertising as being easy is the process of hooking right into the heart of the OS and getting notifications about things happening. The art of correctly using this data to effectively catch malicious code is a much, much more difficult task.


Can JavaScript from different origins communicate securely

I can see two options here.
The first is to just delegate the crypto part to a server, and communicate with it via a HTTP API. This wouldn't involve the JS web crypto API, and perhaps it would violate some of your design criteria.
Second option for communicating across origins is Window.postMessage(). It let's you send messages and receive responses between different window objects in different origins. It is largely up to you to enforce security here:

If you do expect to receive messages from other sites, always verify the sender's identity using the origin and possibly source properties. Any window (including, for example, http://evil.example.com) can send a message to any other window, and you have no guarantees that an unknown sender will not send malicious messages. Having verified identity, however, you still should always verify the syntax of the received message. Otherwise, a security hole in the site you trusted to send only trusted messages could then open a cross-site scripting hole in your site.
Always specify an exact target origin, not *, when you use postMessage to send data to other windows. A malicious site can change the location of the window without your knowledge, and therefore it can intercept the data sent using postMessage.

Note that an XSS vulnerability in any page you accept messages from will let an attacker post messages to your origin.


How can IA-5(1)(b) be enforced on non-Windows systems?

The approach I would recommend for enterprises would be to integrate these systems with your directory service, which for most will be Active Directory. This way your password policy is set in a single place and it bring other benefits in managing access control and roles in a single place. You can also then provide single sign-on and two factor authentication.

Guidance on doing this:

MAC:
http://www.seminars.apple.com/contactme/pdf/L334436B_ActiveDirect_WP.pdf
Linux Ubuntu:
https://help.ubuntu.com/community/ActiveDirectoryHowto

For Cisco IOS however TACACS+ or Radias servers are the best place to set policy centrally.


Stateful network intrusion detection, and even more so prevention, is a tough task in face of multiple upstream links. When traffic can flow in at one link and exit at another, a single monitor cannot reconstruct end-host state effectively. You can either accept this situation with all its implications (e.g., mediocre protection at best) or resort to a distributed solution that propagates state amongst the nodes.

Ideally you would push the monitors to the network edge [1], but it sounds like you have no control over the edge. Without detailed understanding of the network topology, this is a hard question to answer. For the remainder of this answer, I assume that you have at least the ability to deploy several monitors in your network to approximate the ideal of inspecting all upstream traffic.

The NIDS Cluster

The Bro network security monitor has a cluster mode, where a node can propagate state to other nodes. For example, when node A sees a FTP control connection, it may propagate this information to node B, so that it knows how to interpret the following high-port data connection. Another scenario where this comes in handy is distributed scan detection. If you have an infected machine in your network that performs outbound scans through multiple links, each node may keep a local counter and exchange it regularly with other nodes. For a more detailed analysis of state exchange, have a look at the NIDS cluster paper.

Scalability

This cluster approach scales well do to the following insights:

The granularity of analysis and clustering is an entire connection. As long as you can ensure that packets belonging to the same connection end up at the same cluster node, you get good scalability. In single-upstream environments, a frontend typically slices the input traffic to achieve this constraint. In medium-sized networks, a Click router that rewrites MAC address often suffices, but larger environments often have to use dedicated high-performance devices. Our research group has very good experiences with cPacket CVU frontends, which can load-balance multi-10-Gbps links at line rate without dropping packets.
The size of the exchanged state is typically orders of magnitude smaller than the traffic a node observes. For example, if one nodes observes an big ISO image download, it will not propagate the very ISO image to other nodes, but for example just the name of the ISO image. Moreover, intra-connection analysis are already stateful, e.g, Bro follows the TCP state machine and exposes the HTTP message pipeline to the user.

Applying this to your scenario is a little more complicated, because you do not have a single upstream link. In order to scale well, you need to ensure that traffic from the same connection is inspected by the same node. In other words, the notion of a frontend is a little bit blurry because you have to manually route the packets to the corresponding cluster node. The exact overhead of this approach depends on your concrete topology.

[1] This does not preclude defense in depth. Adding more monitors at the core is a good idea as well, for example when no "roadwarrior" subnets are established to isolate mobile devices.


can I enable root access just by using ssh keys and be safe

This depends on how well you protect the private key belonging to the authorized public key.
I see no problem that somebody might brute-force the server directly to get access as root. But somebody might hack your client system, steal the private key and then use it to get root access to the server.


What does it mean to be FIPS 140-2 compliant?

It is a security standard provided by the US Government and a requirement when working with the government. Products that meet the standard are certified and audited to meet certain requirements, partially which crypto libraries they use. Devices that have this standard are not guaranteed to be bug-free but have some level of the audit to them.

Is it enough to use FIPS 140-2 algorithms?

It means that your library has the potential to meet the standard if configured correctly. And can make audits easier as you can point to compliant libraries.

Or should we get a FIPS 140-2 approval?
Who is your customer base? Does this base need the standard, or would it allow you to move into new desired markets? Notice Windows support the standard, but it is not enabled by default. FIPS tends to add restrictions to your design choices and recommend older, more battle-tested algorithms, so using it will limit your ability to use newer major break-through if needed or desired.

Should we receive the FIPS 140-2 approval for each component?
Or enough to receive it for OpenSSL? Or should we receive the approval
for each library that handles cryptography?

The process will vary on the product created and usage. It's best to talk with the audit company about that. Many should be able to give you an idea of the process before you need to pay them.

What happens if we update a library? E.g., we upgrade OpenSSL or Bouncy
Castle.

Update or changes to the product may require recertification, and best to talk to the auditor.

Should we receive the approval once again?

Not sure what ask is here, but I would get if required, or you feel it would increase a goal enough to justify time/expense. In general, audits are not fun.


What are the real-world implications of duplicate SSH fingerprints across many devices?

First it means that there is no way to authenticate a given machine using this key. Since they all share the same key, signed content can come from any of them.

Second, if the private key happens to be broken, you can impersonate 250'000 devices at once.


How to securely get a key from a key server?

They publish their CA certificate on their website. Verify that you are accessing it securely (HTTPS with no errors), then download it. You can also verify its signature and fingerprint (all listed).
They also have instructions to tell gpg to use a local CA to verify the connection:

hkps.pool.sks-keyservers.net
This is a pool containing only servers
available using hkps. Regular A and AAAA and SRV records are included
for port 443 servers, and a lookup is performed for _pgpkey-https._tcp
on the individual servers to determine if a hkps enabled service is
listening on another port. At this point, however, servers not running
on port 443 are not included.
This pool only include servers that have been certified by the
sks-keyservers.net CA, of which the certificate can be found at
https://sks-keyservers.net/sks-keyservers.netCA.pem [OpenPGP
signature] [CRL].
For GnuPG 1.4 and 2.0 installations this can be used by using the
following parameters in gpg.conf:
~/.gnupg/gpg.conf:
  keyserver hkps://hkps.pool.sks-keyservers.net
  keyserver-options ca-cert-file=/path/to/CA/sks-keyservers.netCA.pem

GnuPG 2.1 users prior to version 2.1.11 (starting with this version
the certificate is enabled by default for this pool) want to add the
following in dirmngr.conf:
~/.gnupg/dirmngr.conf:
   hkp-cacert
   /path/to/CA/sks-keyservers.netCA.pem


Can a virtual machine program view a host machine's connections?

Your XP box should only be able to find out that it is a virtual machine(via hardware detection) and where the RDP connection appears to originate from. I say "appears" because this can be gotten around with technologies like Network Address Translation(NAT).

VMWare might have a bug in their code that allows code from within the virtual environment to escape and run on the physical host. I feel that, in your case, you are probably(See @D.W.'s comment below) safe from that because you are running a different operating system.

Under a default install of VMWare, it is possible for code on the virtual machine to attempt to connect to the physical host via SSH, SMB, or other similar network protocols, including RDP. The way to prevent this is to turn off networking entirely for the virtual machine. However, this will also prevent RDP from working. Short of disabling networking entirely, set the virtual machine to be in a host-only network and make sure that your Ubuntu firewall is turned on. Ubuntu should be set to reject all connection attempts from the XP machine.


Where do you get the DigiCert CRL distribution point?

The certificate you referenced is a root certificate. Root certificates do not include a CRL distribution point, because root certificates cannot be revoked.

The CRL distribution point URL you are looking for is included in (all) certificates issued by that root certificate. You can use tools like crt.sh to search for a certificate issued by that root. Then choose a certificate that was issued by that root and inspect it to get the URL of the CRL distribution point.

Here is the CRL distribution point URL you are looking for:
http://crl3.digicert.com/Omniroot2025.crl


Storing sensitive info in DB with Public/Private Asymmetric keys

Using PKI (Public Key Infrastructure) for this doesn't make much sense if your users are actual users of your website / service. HTTPS is already doing transport layer encryption for you.

What you should do is data tokenization + encryption + compartmentalization.

A possible solution would be to setup a dedicated database and server that is separate from the rest of your application ecosystem, and use data-at-rest encryption for your database. In addition to this you can also use application-layer encryption to be extra-safe. (All this done using AES).

This database would be solely responsible for storing this PII (SSN's in your case) and therefore would associate every SSN with a random UUID that can be used in your "main application database" in liue of the actual encrypted data. This random UUID is essentially your foreign key to the sensitive data stored in the secure encrypted database.

This lets you put in place stricter ACL's and permission policies governing access to the encrypted database. For reading and writing you can have separate access policies, having separate access keys for reading and writing.


Spam email "via" my domain, but SPF record exists

Having an SPF record in your DNS records helps the recipient know which email server is legtimiate for your domain. The recipient looks up the sending domain for the valid server IPs and then decides what to do with the email.

If the sending IP is on the list, then the email is likely OK.
If the sending IP is not on the list, then it should be treated suspiciously.

This checking logic requires that the receiving email server is configured to check for SPF records. If you are not checking for SPF records, then the entire SPF checking process is not done.

If your email headers do not include the SPF fields, then your email server is not set up to check for SPF and it is not protecting your company in this way.

You need to look up your email service documentation to figure out how to turn on SPF checking.


Does encrypting a key (stored in cookie) increase security?

Your threat model is incomplete. Here are some of the things you missed:

1) The master key and server key appear to be static values. This means the cookie value is constant and anyone that has the cookie value can replay it to the server to steal (spider) all the plaintext data for that user.

1a) Cookies gets stored in other locations too such as proxies.

2) If the server is compromised an attacker can brute force the master key space to decrypt the user data on a per user basis. The success chance of this depends entirely on the master key length and encryption algorithm.

3) A user can derive the server key. As they know the master key and can view the cookie they can brute force the server key offline. Again success factor is dependant upon key length and algorithm.

4) It's unclear if the service is being delivered over an encrypted of plain text connection. In the case of the latter both the master key and cookie value can be observed by an attacker on the same network. If the former the connection may be downgraded or other vulnerabilities may exist.

5) If the attacker hacks the server they can modify the login code to keep a copy of all master keys it receives. It is common for breaches to go unnoticed for months/years.


Auto-login to refresh token in Burp Suite 2

Recently portswigger has added in the functionality to record the authentication process within burpsuite. Burpsuite will then be able to authenticate if its current session expires or it becomes unauthenticated. This functionality is available in version 2020.9.2 and onwards.
Source: https://portswigger.net/burp/documentation/desktop/scanning/recorded-logins
Is this the functionality you are searching for?


Risks and challenges of an online voting system. Any recent updates?

IMHO authentication over Internet with a security level compatible with a governemental election requires strong authentication (certificate) where the private key is securerly locked into a physical device to prevent any copy. That means that we need a national PKI system where each citizen has a smartcard. BTW, that would de-facto exclude voting from a smartphone.

Then any citizen is normally allowed to vote, even if they own no computer or have an out of use computer at time of vote. So the system should make provision for public voting point for example in town halls.

Once these two points are solved, the next and probably harder one is how to prove that the system does what it is supposed to do. Develepment of a system able to:

identify a voter
note that he/she has voted to prevent multiple votes
store the vote in a way that it is impossible to know at the end who voted what

is probably not a real challenge, but proving that it contains no trap (be it volunteer or not) is at the limit of what I can imagine, because only IT security experts could do it, and I currently know no comitee that would have both the knowledge and competence and the legitimity for it.

And after the election, it would be necessary to again prove that the system has not been hacked during the operation, with the same question on competence and legitimity.

Lawyers generally say that small is beautiful. When you have thousands of vote point each with some people mandated by the different candidates to control the regularity, it is admitted that there will be problem here and there, but not enough to change the result of a vote. Hacking a global system would certainly be harder than adding some paper bulletins, but the consequences could certainly change the result of an election.

That's probably the reason why, while plenty of people would be able to build nice voting system, few countries use them


Impact of using a NON-SSL/TLS connection for API calls on same server

Traffic to the loopback address (127.0.0.1) will not leave the machine it is on, and is thus secure if your server is secure.

If your two example IP addresses point to the same server, your server should recognize this and again prevent traffic from leaving the server.

However, if those IP addresses are for different servers, there is a possibility for an intercept of the data as it flows across the network. This risk might be somewhat mitigated if the servers are on the same private network or in the same datacenter. SSL/TLS can help protect against this.

Restricting API access to specific IP addresses is a good strategy of reducing the risk of unwanted data access, but it does not eliminate it. As I mentioned, traffic interception is still a risk if the network traffic is unencrypted.

Also, with regard to spoofing, it depends on the exact protocol you are using. Protocols using TCP (HTTP is performed over TCP in the standard case), have some resistance to IP address spoofing, but there are still attacks that allow for IP address spoofing in some circumstances.


There are three (soon four) versions of TLS, each with its own RFC (plus a retrospective historical one for SSLv3), but at the basic record level for unencrypted records -- which is, initial handshake records through first CCS or alert -- they are the same.

RFC5246 for TLSv1.2 in the section on ClientHello defines at the top of page 41 that structure (ClientHello) to include SessionID session_id. Similarly for ServerHello at the bottom of page 42. Note that HelloRequest is also classified as a hello message (and a handshake message) but does not contain a session_id or indeed any body at all. SessionID is defined on page 40 as

opaque SessionID<0..32>;

You should recognize that syntax as a variable-length vector previously explained in 4.3 which also explains how the length prefix of every variable-length vector works.

'Empty' means no bytes in the value i.e. a length of zero, encoded as a length prefix of zero followed by no (or equivalently not any) content. If you think about the encodings defined in section 4 it is obvious that you cannot omit a field from a fixed structure; some (not all) variable-length fields can be empty, and some (only some) structures have variants where you use only the fields of the one variant applicable in a given situation as specified. However, the extension field in Client or Server Hello is defined as a variable-length sequence of items each of which begins with an explicit (2-byte) type, so you can include or omit, and reorder, extension items within the extensions field -- at least for encoding; whether a peer will accept a set of extensions is up to that peer.

If you want to implement TLS you really need to understand the applicable RFC(s) for the version(s) you want 2246/4346/5246, plus several related ones like 3546/4366/6066 for extensions, maybe 4492 (and SEC1 etc) for ECC, maybe added suites like 5288/5289 for GCM, etc.


Is it acceptable to enable relay of emails in an internal email server in a corporate network?

The above method can be used by an internal adversary to spoof and send emails to any internal employee as anyone else. Isn't this vulnerable?

Yes. There is a university of applied sciences in my neighborhood that had such a mail server that allowed any user to use any email address from their own domains. Someone abused it to send around personalized but automated love letters. It was hilarious. The IT department, instead of being in shame after having been pointed to that vulnerability multiple times, went after the person. It was hilarious.

  Is there any justified acceptable reason for allowing internal-internal and external-internal relay in internal mail servers?

You often have an outgoing mail server that your internal mail server contacts for all mails that it cannot deliver locally. These two are often running on the same machine, and it's acceptable to open the mail server port only locally to allow the internal, and only the internal mail server, to directly talk to the outgoing server. The internal server then has the duty of making sure only authorized users can send mail from addresses that belong to them.

  Would stopping this affect the normal functioning of corporate email?

No, because this isn't normal.


What security impact is caused by a TLS server continuing the handshake when presented with an invalid SNI?

There is no security impact to either stop or continue the handshake -- the security relies in the tests performed by the client, not the server. This is why the extension is called an indication. What matters is that the client duly verifies that the apparent server public key is really owned by the intended server. The SNI is a way for the client to convey to the server a hint about the process that the client will use for that verification: namely, the client will check that the server's certificate is valid, and that it identifies a specific server name.

Even if the server sees that the SNI matches its own certificate, the client still has to do all checks.

In case of SNI mismatch (the client sends a name for which the server has no matching certificate), keeping on with the handshake can be somewhat useful in order to send an explicit error message. The human user, on the client side, will have to "click through" the warning, and human users should really be trained not to do that, but if they do, then they may see a page sent by the server that will state exactly that ("This is not the Web site you are looking for"). With an SSL-level alert, all the user will see will be the generic "Could not connect, check your Internet connection" that is awfully uninformative.


Why doesn't a cookie persist across different machines?

What is the extra factor that forces either the browser or the server to require a new cookie? Is it the IP address of the machine? MAC address or something like that?

It is unknown what the extra factor is in the specific cases but it is not uncommon that the IP address or some kind of browser fingerprint is included in the cookie or attached to it on the server side do defend against session hijacking caused by stealing the cookie. MAC address is not included in such checks because there is no way to get such information from within the browser or from the server.

See also Binding the Session ID to Other User Properties in the Session Management Cheat Sheet from OWASP.


Security of the KWallet password encrypting application?

The blog post you quote is quite imprecise in its formulation. However, by looking at the KWallet source code, especially this file (for the password hashing) and that file (for the invocation of the encryption code), we see the following:

The password is extended into a symmetric key of size 20, 40 or 56 bytes (160, 320 or 448 bits) by applying SHA-1 repeatedly. Namely:

If the password has length 0 to 16 characters, the key will have length 20 bytes and be the repeated application of SHA-1 (2000 times) on the password (the password is hashed, then the 20-byte output is hashed again, and again, for 2000 invocations of SHA-1).
If the password has length 17 to 32 characters, then the key will have length 40 bytes: the first 16 characters are processed as above, then the remaining characters are processed similarly, yielding 20 more bytes.
If the password has length 33 to 48 characters, then the key will have length 56 bytes: the first 16 characters are processed as above, the second chunk of 16 bytes of characters as well, and then the third chunk; the output for the first chunk is then truncated to 16 bytes, for a total of 56 bytes.
If the password has length 49 characters or more, then the 2000 SHA-1 invocations will happen four times. For the fourth chunk, the complete rest of the password will be used. The four 20-byte output are then each truncated to 14 bytes, and these are concatenated, yielding a 56-byte output.

As a password hashing function, it is quite poor. It is clunky and not regular. It is not salted, allowing for efficient parallel attacks, when several KWallet instances must be broken (as usual, "parallelism" also means that precomputed tables can be used, negating the slowing effect of the 2000 SHA-1 invocations). Moreover, it "splits" the password, so if an attacker finds a password hash, then he can attack each chunk independently of the others. This means that the security of the whole thing relies a lot on how well the Blowfish block cipher behaves when used as a hash function. This is, at best, a poorly studied property.

The encryption purports to use CBC, but does not. In CBC, you are supposed to encrypt a sequence of blocks (8 bytes per block with Blowfish); before encrypting a block, it is first XORed with the previous encrypted block. For the first block, we must conjure a formal "previous block" which is the Initialization Vector. CBC requires a random IV.

In the KWallet code, we see that the code indeed prepares a random IV of the right size.... then completely fails to do CBC. The call to encryption is:

int rc = bf.encrypt(wholeFile.data(), wholeFile.size());

(line 291 of backendpersisthandler.cpp)

Looking at the implementation for this encrypt() method, in cbc.cc, we see that it will create a temporary buffer of the same size of the whole file; then fill it with zeros; then XOR all these zeros with the data to encrypt (which won't change the data...); then proceed to encrypt each block independently of each other. This is, indeed, ECB mode, not CBC. It is quite obvious that this is a programming error; the lesson to learn, though, is that since KWallet appears to work, then the mistake was not detected: security cannot be tested through functionality.

(This implies that the random IV which was computed does nothing here; it is encrypted by itself but does not impact any other byte in the whole file.)

ECB mode is known to be weak in the following sense: it leaks information about what blocks are equal to each other. For an uncompressed picture, this is deadly, as demonstrated with the usual penguin image. For a KWallet, this is a source of worry: the internal structure has some redundancy, and this may be exploitable, although it would require some effort to ascertain the extent of the issue.

Note that since the password is not salted, two successive versions of the KWallet protected with the same password will use the same symmetric key, so block equalities leaked by ECB apply to all successive versions of the KWallet.

There is a homemade MAC. The last 20 bytes of the file (excluding some padding) contain a SHA-1 value computed over the rest. This is, generally speaking, not a good MAC. It would be an extremely bad MAC if the encryption used RC4 or a block cipher in CTR mode. With a block cipher in ECB mode (as used here), it is not as bad, but still poor.

The whole code reeks of homemade crypto slapped together by someone who did not master the concepts. This is bad. Also, I find the code to be atrocious in many respects (e.g. when the password chunks are hashed, the loop which invokes SHA-1 repeatedly is ruthlessly duplicated; that's a shooting offence). To "improve" KWallet, I suggest deleting the whole code and starting from scratch.

It seems that the code includes some optional support for not doing the password hashing and encryption itself (as we saw, it does it very poorly), but instead using GnuPG. Now THAT is a good idea. GnuPG implements the OpenPGP format which, for all its shortcomings, is at least decent cryptographically speaking (when properly used), and GnuPG is also known to be a tolerably good implementation. To improve storage of your KWallet, see if you can convince your computer to use this GnuPG support code and format.


Is there any proof in support of these basic security guidelines?

This group describes itself as:

Since 2018, the group has concentrated on fundraising from the tech community for candidates for public office.

It claims no knowledge about IT, but it suggests that its advice was found useful. Also, it provides advice for a specific group of people, in the quoted page, for congress members/candidates.
The reason why all the articles are inconclusive or heavily opinionated is that this is normal in our line of work. Very few read the IEEE transactions on computers or any scientific literature. And of course, many security incidents are not reported so statistics are not reliable. There is no real consensus on any of these subjects. For example: all anti-virus vendors produce statistics that anti-virus IS effective, with some underlying statistics.
Alternatives to anti-virus for keeping oneself safe provides a balanced view on anti-viruses.
It is a well-known fact that anti-virus consumes a lot of resources. That should not need any further proof. Others (like datapot.net) state, based on statistics that:

On average, antivirus software is only 25% successful at detecting malware.

Statistics on computer viruses and antivirus software show that, unfortunately, the malicious apps are winning the battle. Currently, “popular” malicious programs are having a field day, even against top-of-the-line antivirus software. There’s no such thing as a fully impenetrable wall; some viruses and trojans pass through completely undetected during the initial encounter with the antivirus.

The effectiveness of Code Signing seems mainly dependent on the signing process. Note that the enforcement of code signing is missing from the advice list given.
The bold statement:

Android phones are not safe to use.

is too general and the statement that IOS would be safe, is difficult to take seriously. Research Siri and its use of subcontractors to listen in, for example.
Browser advice seems more religious than based on reality. Real browser security seems more dependent on the use of plug-ins, Javascript (or, horror: still Flash!) and the likes. Note that ExpressVPN has a different view on the security; they have the following top 7:

Tor Browser
Firefox
Brave
Chrome
Safari
Opera
Edge


There are a lot of (blind) SQL injections in various ManageEngine software. For example you could train on ManageEngine Application Manager before 13730 which has at least one affecting "AMUserResourcesSyncServlet" :
https://manageenginesales.co.uk/news/manageengine-applications-manager-build-13730-released/
It is a blind SQL injection, however dumping data may not be the ultimate goal. It is possible to achieve RCE using PostgreSQL capabilities (default backend provided by manageengine), such as UDF for example. I think this vulnerability has been widely documented :-)
You can download the vulnerable software here: https://archives.manageengine.com/applications_manager/


How to deal with spam that contains my personal details?

Your name, email address, and street address are not exactly secret information.  It's far more likely the data was either scraped, or purchased from some legitimate (or quasi-legitimate) source than stolen in a data breach.

In any case, regardless of whether it was purchased or stolen, yes, it's safe to ignore, or rather go ahead (since you're using Gmail) and report it as spam.  Then, forget about it.  If they could (and wanted to) use the data for identity theft, then they'd have gone ahead and done that rather than to waste their time sending you spam.


Does Windows log desktop application passwords?

I do not believe Windows stores app credentials by default.  But Windows CAN do almost anything you (or an attacker with sufficient access) tells it to.
I think it is important to distinguish credentials (your password) and session management (access to the application).  These patterns and advice apply to most client-server applications.
Applications are free to implement credential management and session management however (securely) they want.  Many have made mistakes.
"Remember me" functionality is usually session management...  the client computer will store a token that is authorized to resume an existing session (without requiring credentials) on the server computer.
If an attacker can access that client token, they might be able to resume your server session.  If an attacker gets your credentials, they might be able to start a new server session.  Both scenarios are bad obviously.
Multifactor authentication, and not-using-untrusted-client-devices are good ways to protect your credentials.  Secure transmission too obviously.
Session management is tougher, as most of it is invisible to the user, and is implemented many different ways.  If you're worried, usually a password change on the server will invalidate previously created client sessions.
I hope this helps!


What information is exposed by simply opening an RDP connection to the internet?

I do not believe this is a very good thing. There are simple programs on the net which can attack, and exploit vulnerabilities is RDP.

I suggest they look into secure VPN instead on directly opening their domain up onto the net.

If you want the serious truth:

Using TSgrinder, an attacker could try a brute-force attack using customized lists of username/passwords. Though this method takes a considerable amount of time depending on password complexity, it still is a potential threat to the network security infrastructure.

VPN on the other hand is encrypted, and secure, and takes an attacker a lot more effort to attempt to break it. It keeps ALL data transfer safe, and provides ease, and simplicity to both the back-end management, and end-user.

Hope it helps ;-)


(Public) IP address [x.x.x.x] of Synology has been blocked by SSH

I might found the culprit, at least in my case, rsync.
I use rsync on my NAS and that port is open, has port redirection on my router and guess what it uses SSH, so that would explain why my NAS gives me those same SSH warnings eventhought SSH is turned off on my Synology.
Have had no more logs about bruteforce attempts on SSH sofar since I closed the port today.


No, and it will give you nothing but headaches.

What happens when your email server has to email an MTA that just so happens to have the same IP address as a machine in your subnet? Or when that website your user needs to go to has the same IP address as a machine in your network? Default routes are created saying "If this machine doesn't exist in this network, send it to through the gateway to find said machine", but if that machine is found on your network it will never reach the gateway.

I assume one might think that there is a security benefit by using unconventional IP addressing might deter an attacker footprinting your network, when in actuality if he pops a box he's going to look at the IP address scheme and just scan that network. It won't matter if the network is 10.10.0.0/16 or 123.123.123.0/24.

Private address ranges were invented for a reason and not using them provides no additional security benefits. There is a litany of reasons why "Security through Obscurity" is not a sound security concept, so please save yourself the hassle and just use those in the RFC.


Is it possible to classify Wi-Fi Security Level without connect to Wi-Fi

Yes, it's possible. I do a lot with the ESP8266 micro controller, and it's API offers a wifi scan that returns the SSID, encryption type, signal strength, hidden/public, etc.
How you perform such a scan depends on software and the device, but it's possible 100%.

Doc ref: https://github.com/esp8266/Arduino/blob/master/libraries/ESP8266WiFi/src/ESP8266WiFiScan.h#L43


Can Windows take data from other OS running on same hardware?

Yes, in regular configuration, Windows can read the Linux partition and vice versa.

If you want to prevent this, you can encrypt your Linux partition and Windows partition with separate encryption keys. This way, only one partition can be unlocked at a time, so neither OS can get data from the other. In Linux you can use LUKS, and Windows you can use BitLocker for this purpose.

Note that some very advanced malware exists that can infect the hardware/BIOS and persist between dual boots and OS reinstall. These types of malware are relatively rare and often very hardware specific, but these types of malware may have the potential to cross between OSes despite dual booting and encryption.

There are also malware that may infect the boot partition. This type of malware can be prevented to some degree using Secure Boot.

Virtual machine changes this slightly. The host machine would be able to access the guest machine's date, but the guest machine won't (depending on configuration) be able to access the host machine's data. The only exception is a blue pill type of malware that can break out of the virtual machine. This type of malware is also relatively rare.

In short, if you want absolute guarantee of separation, then separate hardware is the only way. However, in practice, using disk encryption would make it very, very, very hard for most malware to steal data from the other OS.


Buffer overflow, SIGV fault at wrong address

That location is not weird, it's right in the middle of your shellcode. First verify that your shellcode is not broken. The disassembly of that code reveals this:

0x00000000: push 0xb
0x00000002: pop eax
0x00000003: cdq
0x00000004: push edx
0x00000005: push 0x702d
0x00000009: mov ecx, esp
0x0000000b: push edx
0x0000000c: push 0x68
0x0000000e: das
0x0000000f: bound esp, qword ptr [ecx + 0x73]
0x00000012: push 0x6e69622f
0x00000017: mov dword ptr [ebp + 0x33], esp
0x0000001a: push edx
0x0000001b: push ecx
0x0000001c: push ebx
0x0000001d: mov ecx, esp
0x0000001f: int 0x80

Are you sure this is what you really want to achieve with your shellcode?

Secondly, make sure any instruction of your shellcode is not overwriting parts of itself. If the stack pointer is right after your shellcode, push instructions might clobber it from its tail, leaving invalid instructions to execute.


The hardware tool that is suited to his is the Universal Software Radio Peripheral (vendor site). You can get a leg up on decoding the transmissions by looking at the work done for the OpenBTS system. So, hardware-wise it's commodity equipment, though a few thousand dollars because it's not very common. Software wise, the groundwork is already there to pull from.

Cellular data is typically encrypted between handset and tower, and so far most attacks against that have ben active. Thus, complexity of sniffing usable data may be relatively high / a research project.


Home "datacenter" security, where and what to look for?

If it was me I would create a spreadsheet with 2 columns in it with the first one defining the piece of security Ex. •Keypad/Security door •CCTV •Strong Firewall and in the second column back up why the items listed in the first column are considered secure.  For example CCTV | The CCTV system records footage locally and also sends real time alerts to X number of email addresses and one of those is on my personal smartphone so I would be notified immediately. Secondly if power was cut to the device it is powered by a battery backup device that will suport up to XX:XX of recording time on battery only power. Third the system has two different connections to the internet through two seperate networks one hardwired and the second one through a seperate 4G or Neighbors WiFi (with permission).

The possibilities are endless but when I try to sell a solution to a client it's very easy to organize a 2 column spreadsheet outlining the benefits.(Think Cause and Effect) Item A provides this solution, item B provides that benefit, etc. As for certification, I don't know where to point you to, however there is a loophole to this. Certification just means that a third party of some sort states that your configuration is what you claim it is. You could find and or create an entity that would do this and create some type of certificate to show off to your friends or clients. You may want to consider consulting with an attorney if this is the path that you want to take. If you have prepaid legal / Legal Shield you can call them for free consultation under title 1 of your benefits and they would be able to tell you the legality of the "certification" process.


The fact you're seeing this service and port suggests you may be scanning a Domain Controller, for which both UDP & TCP ports 464 are used by the Kerberos Password Change.
This port in particular is used for changing/setting passwords against Active Directory.

Doing an nmap -A might help you identify which version is being run and could assist in helping you work out what type of attack it's vulnerable against.

On a side note, if you're like me and find it useful to know why that service exists, the one in question has a good read up here.


COPE vs. BYOD - as an employee why should I be interested in BYOD?

For some employees, MDM might be a valuable benefit. A few years ago, a coworker told me he always used the company VPN when browsing the Internet from his personal computer because (he felt) it was safer. Features like remote wipe of your data or having someone (e.g. at the Help Desk) who will listen to you and help you if you lose your device could be compelling for some employees.

As far as why an employee might want BYOD: I'm not high-ranking enough to get a corporate-owned device (and even if I was, I wouldn't want to have to juggle two phones), but it can be nice to be able to check my email or calendar when I'm away from my desk. Sometimes on a pleasant day I would check my calendar and email and, if there was nothing urgent, take the long way in to work. When my employer started requiring MDM I gave up that perk; other people less concerned with control of their phone might make a different decision.


A false negative is when biometric systems fail to recognize an authentic individual, which would lead to something not happening. Depending on what that something is there could be various consequences:

Personal: An owner of a safe may be prevented from accessing that safe, leading to him/her being unable to access a necessary resource. Say they really need the money that's in there
Institutional: Say my entire server infrastructure is down, I need to access my data center to restore service. Ever minute is losing my company thousands of dollars in revenue. The biometric system doesn't recognize me, therefore the company loses more money and reputation
Safety: A staff member in the datacenter collapses on the floor in cardiac arrest, the biometric system doesn't recognize me when I try to go to her CPR. She could die before I get to her


TLS-Handshake, Server Key Exchange, Diffie-Hellman: Where does key length come from?

For TLS through 1.2 in most cases (see below) using DHE key exchange, the DH group (prime p and generator g of suitable subgroup of Z_p^*) is sent by the server; the client has no influence beyond specifying a list of ciphersuites that does or does not lead the server to select a ciphersuite that uses DHE (at all).

In general server software (or firmware, or middleware as applicable) varies in how it determines the DHE group to use. Some servers are hardcoded, and some are configurable; if configurable the method of configuration and options available vary wildly. However, it would be pretty aggressive for a server today to hardcode 4096-bit DH, so I'd say it's reasonably likely this server is configurable somehow.

Since you give no clue what the server is, it is impossible to give any useful answer as to that 'how'. Although if it is any of the more common ones like Apache httd, nginx, haproxy, or Tomcat (including Jboss/Wildfly/whatever it is today) you can probably find documentation and/or existing Qs here or superuser.com or serverfault.com or maybe unix.SX by searching something like "{server [version]} configure DH".

Technically there is an extension to TLS1.2 (and earlier), RFC7919 which does allow the client and server to negotiate among a standardized (specifically, IANA-registered) set of groups. But I'd be surprised if a client that can't support DH over 2048 bits supports RFC7919. You can confirm this by looking at the extensions in the ClientHello message in your capture. TLS1.3 uses only the RFC7919 groups for DHE, within its substantially new scheme for doing keyexchange, but you aren't using 1.3.

Depending on what other ciphersuites the client offers, it might be possible to configure or otherwise induce the server to choose a non-DHE ciphersuite; in that case there's no issue of the server using DHE parameters the client dislikes. Especially if both client and server support any ECDHE ciphersuite(s) with acceptable other parameters (auth and data cipher/MAC), that would provide the same forward-secrecy benefit as DHE but be more likely to interoperate successfully since for ECDHE (pre-1.3) practically everybody implemented the former Suite B curves P-256 and P-384, and maybe P-521.


Is placing an `autorun.inf` folder in a drive's root a good safety precaution?

Well, it might help. Better yet, make your computer not to obey autorun.inf on removable drives (but assuming you plug your usb into another -infected- system, it can help noticing it).

There is a solution taking the next step, USB Vaccine, which creates a unwriteable, undeletable file with that name in your usb drive. It does so by marking it with some extra bits at low-level, so the normal fs aren't able to remove it (the program can uninstall it, of course). Virus are very unlikely to go down at such level just to remove an autorun.inf

But regardless of that, disable its execution. And remember that there are more ways of getting infected via usb than due to an autorun.inf.


When knowing an individual's plaintext password history, how much information is expected to be gained with a new password? Do we know this?

Answering my own question a few months later -- it turns out there is some (very recent) research here.

Beyond Credential Stuffing:
Password Similarity Models using Neural Networks by Bijeeta Pal et. al. introduces some work that cracks passwords by using a users other known passwords, and introduces the concept of a "personal password meter"

I'm not an expert here, but this looks like an interesting first reading. The citations are especially useful, and link to some related works.

As far as I know, as of now (Nov 2019) there aren't any ready-to-use tools like JackTheRipper or HashCat to do this.


What is the difference between Right and Permission?

I don't think there really, really is a totally good reason for the distinction. It's just the way it wound up in Windows.
In everyday language rights/permissions/privileges are somewhat synonymous anyway.
Re. "User rights"
The term "User rights" on Windows usually refers to something granted to a user.
Microsoft themselves seem unsure about the terms. Here's a painful bit from Wikipedia:
https://en.wikipedia.org/wiki/Privilege_(computing)#Nomenclature

The names used in the Windows source code end in either "Privilege" or "LogonRight". This has led to some confusion about what the full set of all these "Rights" and "Privileges" should be called.
Microsoft currently uses the term "User Rights". In the past some other terms have also been used by Microsoft, such as "Privilege Rights", "logon user rights" and "NT-Rights".


Does the WP(Write Protect) pin of a USB flash memory controller prevent tampering with its firmware?

No.
The firmware, kind of a little OS running on the USB drive, is a mediator between the OS where the device is plugged in and the NAND flash.
If you make the device write protected it means the firmware now tells the PC that it can't write to the device.
This can't be circumvented by a well behaving OS, the USB stick will just block writes. But since the firmware has bugs too malware still could work around that and write to the device possibly updating the firmware itself. On the next "boot" (unplug/plug) of the device the malicious firmware can be loaded.
For real write protection you need to block writes at the NAND layer. This has a WP pin which needs to be pulled to ground (check the data sheet of the chip to be really sure).
To my knowledge no USB device with WP switch does that. You can check yourself by testing the voltage of the WP pin.
When you manually pull the WP pin to ground the flash is write protected but the firmware won't know about it. Hence you still can  "write" to the device but you can't read the file back or on the next "boot" the file will be gone.


Is it possible to block specific users that connect to the internet behind of same gateway with NAT?

In the general case, no.

In some specific cases, you can.  For example, if you're running a webserver and the gateway's NAT modifies HTTP requests to include an "X-Forwarded-For" header, you can use the XFF header to distinguish and block individual computers (assuming, of course, that the gateway is honest).


How Does Telegram's Identity Verification Work?

WhatsApp derives the QR code (and the numerical representation) from the user identifier and the 32-byte public Identity Key of both parties. I guess that some deterministic algorithm decides, witch of the two identifiers comes first (e.g. they could be sorted lexically).

This allows both clients to display the same image and numerical representation, whilst providing the same security as for example Signal, where both fingerprints are displayed individually.

Telegram uses a slightly different approach, because it computes a new secret chat key for each new secret chat (even if you are already participating in an active secret chat with the same person). Therefore, every secret chat with the same person should display a different 2D code and in my understanding it should also frequently change.
This is due to the fact that the secret chat key is computed using Diffi-Hellman and is regenerated every 100 messages or at least every week, to provide some sort of forward secrecy.
Both participants of the secret chat should see the same 2D code (which is some sort of graphical visualization of the secret chat key), since the secret chat key is a shared secret between both participants.

I am not completely certain about the Telegram part, because I don't use Telegram myself.

The information is taken from the WhatsApp security white paper (April 2016) [1, page 8] and the Telegram API documentation [2].

[1] https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf

[2] https://core.telegram.org/api/end-to-end


What is more secure practice? Hosting from CDN or Main website

my understanding is its not possible to specify individual JS files. instead the principle is you trust the CDN provider in this case you trust google. I think it would be a nice extension to the CSP if you are allowed whitelist the domain and JS resource.


Is it correct to assign a CVSS to a misconfiguration?

As noted in the comments, your HTTP example would not be a misconfiguration. But, certain configs can result in or amplify vulnerabilities. For example, if a endpoint on a web app does not enforce authentication (when it should), this would be labeled as a “security misconfiguration vulnerability” on a Pentesting report because it allows an user or attacker to bypass security controls and also rated as High risk.

So I would answer yes, configurations can be a vulnerability because it can expose you to attack just like any other type of vulnerability.

And you can assign a cvss score to a configuration,  but if it makes sense is another question...


What security has OSX and why it does or does not need antivirus

The idea that "my OS doesn't need antivirus" is patently wrong.  I saw a presentation some time ago that said that something like 90% of viruses/malware are written for Windows.  That leaves around 10% for other platforms, such as Macintosh/Linux/Unix.  Granted that percentage is small relative to Windows, but the important thing to note is that it exists and that malware for those platforms exists.  I'd also note that the amount of malware written for the Mac platform is growing (CIO magazine)

Malware is also written for 3rd-party plugins, such as Flash and Java.  Those don't really care what OS you run.

I say this a lot: look at what happens if someone is wrong.  If your CSO is wrong and AV is not needed, they've wasted the company's money.  That's really all that has happened, and that's the CSO's problem.  However, if you're wrong, you have malware on your Macs and no easy way to detect and control it.  And when it somehow gets discovered, you're going to look foolish if not unemployed.

There are many antivirus vendors out there.  For larger enterprises, McAfee seems to be a popular security suite.  For 100 users, you probably don't need all the admin tools and other features that McAfee offers.  You can check out Tom's Guide or other sites to look at ratings for how effective antivirus suites are.

Do a quick Google search on "Wannacry on Mac" and you wind up with a lot of results.  I'd suggest reading the Intego and CIO articles, both of which support my main point - that Macs need protection.

I'm not an expert on securing Macintosh, so I'll leave that to folks who know more than I do about that particular subject.

Edit: Within an hour of posting this, a new thread on malware for Mac has appeared on this forum, which only further supports my point.


End-to-end Encrypted Group Chat Considerations

Overall
I would recommend that you use hybrid encryption.
It's more performant than using "only asymmetric encryption" (public-private-key). Some problems could even occur when you encrypt very long messages with asymmetric encryption.
The server should never know the symmetric keys. It's main task is to guarantee the transmission of the messages.
2-party-E2EE
The first "message" between two parties is the exchange of a symmetric key via asymmetric encryption. This is to increase the performance of all succeeding messages (symmetric encryption and decryption is faster than asymmetric encryption).
Mulit-party E2EE
This basically works the same way as the 2-party-end-to-end-encryption. The simplest method would be this:

The admin of the group chat creates a (random) symmetric key.
The admin sends this symmetric key to each recipient of the group via asymmetric encryption.
All further messages are then encrypted & decrypted with this symmetric key.
If a new party joins the group then this symmetric key can be sent to this party as well, if you don't care that these members then also can decrypt previous messages. If you don't want them to decrypt older messages, then the 1. step is repeated.
If a party leaves the group then the 1. step is repeated.

Edit: I should probably also add that there are definitely more details to it, but this shows the basic functionalily.


Is there an issue if application responds with access control allow origin * but there is no allow credentials header?

No, if the server's API follows REST principles (which it should).
If in a fetch with GET you set credentials: "include" then the request will be performed and credentials will be included. But:

response's content won't be made available to the browser when either Access-Control-Allow-Origin: * or Access-Control-Allow-Credentials: false (or if either of them is missing). So the client won't be able to read the response even if the server responded with something user-specific.
since this is a GET request then the server shouldn't do anything state-changing (this is the "follow REST" part)

Using POST, PUT or DELETE in a cross-origin fetch with credentials: "include" will require a preflight request beforehand -- to ask the server if these methods are allowed to be performed with credentials. So if the server does allow credentialed state-changing requests then it must reply to the preflight with headers Access-Control-Allow-Origin: https://the-clients-origin.com and Access-Control-Allow-Credentials: true.
(There is a slight exception to the previous for POST requests with content-types either application/x-www-form-urlencoded, multipart/form-data or text/plain. These are there for cross-origin form-submit handlers (someone correct me on this).)
Read more on MDN: CORS: Simple requests or Fetch specification.


Is it possible to find a buffer overflow in WordPress?

As PHP does memory management and a lot of stuff by itself, finding a buffer overflow specifically in WordPress doesn't really make sense to me.

Before discrediting that Penetration Tester, I'd ask him/her for documentation of the finding in question. As he/she works for said client (sounds like it, correct me if I'm wrong), it's his/her job to report such an issue to the client, including a documentation of at least a way to track down/reproduce the issue.

I'm very sceptical, as you say, that he/she only had access to the webservice from the outside. Verifying a low-level issue like a buffer overflow (which is even way beyond the webservice or wordpress in general) is next to impossible from the outside.

Executing one is tricky, even if you have access to the source code, which doesn't seem to be the case (assuming it's not a whitebox test).

P.S.: If you get an answer from the client/pentester, I'd love to hear it. You got me pretty curious for some reason...


What's the difference between `aes-128-cbf` and `aes-128-gcm`?

That last part refers to the mode of operation of the cipher.

GCM is the Galois/Counter Mode which provides authenticity. You probably mean CFB for the first one, which is the Cipher Feedback Mode, an older and more simple one that provides no additional function.

The main differences between cipher modes is what they are optimized for and what features they provide. Many require an IV, but some only a nonce. Some leak patterns (ECB), most don't. GCM includes a MAC, most others don't. GCM is also optimized for performance.


Is a hosting company right in disabling all but TLS 1.2 as acceptable protocols to do SSL with?

Is it common for clients to not have TLS 1.2 or have it disabled in 2017?

All modern TLS clients support TLS 1.2. It is not that common that a client supports TLS 1.1 but not TLS 1.2 because most major TLS stacks like OpenSSL (Unix, Android), SChannel (Windows) or NSS (Firefox, older Chrome) started to support TLS 1.1 and TLS 1.2 at about the same time. A reason for this is that TLS 1.1 was standardized 2006 and TLS 1.2 2008, i.e. shortly after and most TLS stacks did not start to support either of these protocols until 2012..2014 so they then implemented both at the same time.

It is still common that some clients support neither TLS 1.1 nor TLS 1.2 (older Android, older Windows) but supporting TLS 1.1 and not TLS 1.2 is uncommon.

On the server side most sites offer TLS 1.0, TLS 1.1 and TLS 1.2 while some sites with higher security requirements (like Paypal payment API) require at least TLS 1.2.

  Can a LAMP Webserver be patched to handle 1.1 TLS, alongside offering the more secure 1.2?

If you have full control of the server (which usually requires root on the system) you should be able to enable TLS 1.0 and TLS 1.1 and also only TLS 1.1 alongside TLS 1.2. If you don't have full control and only share the same web server with other users you cannot do this.


What fraction of vulnerabilities does black-box pentesting find?

One paper in the literature provides some partial data on this subject [1].

The paper analyzed 9 web applications using two methods: (1) black-box penetration testing, and (2) manual code review by an expert.  It compared how many vulnerabilities were found by each.

In total, the analysis found a total of 91 vulnerabilities.  39 of
them (43%) were found by black-box penetration testing.  71 of them
(78%) were found by manual code review.  There's no way to know how many more
vulnerabilities might be present that neither technique discovered.

Therefore, one possible conclusion is that black-box penetration testing finds less than half of all vulnerabilities present in a web application, on average.

Another conclusion is that the combination of both methods seems to be better than either one alone; they each detect some vulnerabilities that are missed by the other.  In the paper mentioned above, neither method alone was enough to detect all vulnerabilities:
manual review found 52 vulnerabilities (57%) that were not detected by
black-box pentesting, and black-box pentesting found 20 vulnerabilities
(22%) that were not detected by manual code review.

However, this paper has a number of limitations.  It looks at only 9 web applications.  It is hard to know whether these are representative of all web applications in the wild.  Manual code review was performed by only one reviewer.  Black-box pentesting was performed by only one tester, and using only one tool.  It is not clear whether the effectiveness of these methods might vary from person to person, or from pentesting tool to another.  Therefore, this data is only a first glimpse, and can't be treated as the final answer.

[1] Matthew Finifter, David Wagner.
Exploring the Relationship Between Web Application Development Tools and Security.  WebApps 2011.


Is it possible to send the user a randomly generated password while still storing it securely in the database?

The best idea here, to avoid storing the password at all, is to have a key K that only your server knows.
Then when a user signs up, you create a link like:
signup.php?username=xxxx&email=myemail@domain.tld&password=randomrandom&expiry=nnnnnnnnnn&hash=(*)

(*) then consist of sha256(K + ":" + myemail@domain.tld + ":" + xxxx + ":" + randomrandom + ":" + nnnnnnnnnn)

By using this method, you don't need to store anything at all. When user signs up, the only thing that happens is that above link is generated and sent, nothing is stored in database.

When the link is clicked, then the account is created for real. (Of course, you need to recheck that the username is not taken and that the email is not already registred for example)

This ensures that nothing needs to be stored until the action has been fully completed by the user.

You can also have that above link to directly create & login the user (without any initial random password) and have the user select a password on first visit.


Exclude passwords with repeating letters

I think it's fair to say that 5 truly random letters are going to be less likely than 5 repeated letters, even if "aaaaa", isn't practical to type...the people who make these passwords have avoided much practical thinking.


safe money transfer on open wifi VS vpn not allowed

Banks do not block all VPN, but they might block known VPN which are advertised for anonymous surfing or similar. Because if such a VPN is advertised and used to hide the origin of the user then chances are high that it will be used for illegal activities too. This means an increased risk for the bank and it's users if the bank accepts orders for money transfers this way, because it's harder to verify the origin and legality of such transactions.

If you instead setup your own VPN so that it looks like that you connect from your own home then it should be no problem to use the online banking. If and how this can be done depends on your setup at home.


Server attack attempts, what are they trying to achieve?

All of the exploit boards are exploding with the recent Apache + PHP 5.x remote code execution vulnerability.  Every HTTP server on the planet is getting hit with this right now.


Why doesn't WannaCry ask to "make changes to this computer" when you run the exe?

I don't exactly know what WannaCry does, but it wouldn't need permissions to change your personal files, only to change system files. You don't have to grant permission everytime you change a file with word. Its similar for WannaCry.


How do I prevent data from leaving my network?

I was asked about your problem several times in several occasions. What makes it really difficult to answer is, that this in fact isn’t really a tech-problem. It's much more a social/human problem.

There are many great firewall-systems like SonicWall/FortiGate/etc. (also VM-Based solutions) which will cost you maybe only 500$. They are all able to block protocols / ports / sites / etc for you but... in my opinion you would need to block every site and every connection between your source control network and the internet, because there is always a way to use an established connection to get the source-code out of your business-place.
Even if one uses something simple like putty to establish an ssh-connection over port 80 and tunnel ports trough it for all kind of protocols like FTP/SMTP/whatever.

My advice to you is, don't try to get to an expensive technical solution when this really is a human, social problem. There will always be a way to get your source-code out of your place. (usb, cd's, photo via mobile phone? If someone wants to do so they will succeed...)


For the specific situation you are alluding to, using a symmetric key and RSA keys is the right path. Namely:

Data is encrypted with symmetric key K (with AES or some other algorithm which does the job).
Every user who should have access to the data has a RSA key pair. Each user has his own key pair, distinct from that of any other user. Let's call Pu the public key of user u (and Su the corresponding private key).
K is asymmetrically encrypted (RSA) with the public key of each user. This means that the database contains several values EPu(K) (encryption of K with the public key of user u).
When a user wants to access the data, he uses his own private key Su (from his flash drive) to decrypt his value: DSu(EPu(K)) = K. With K, the user can access the encrypted data.
When you want to add a new user v, you generate the new key pair for that user (Pv, Sv) with the private key stored on a new flash drive which you give to the user. You also encrypt K with Pv and add the new EPv(K) to the list of such values in the database.

Removing a user is tricky, because of a general fact: you cannot enforce forgetfulness. Any user who had access to the data at some point could have grabbed a copy of the whole (decrypted) data and still remember it. The best you can do is to make sure that the removed user will not have access to the new data added after the eviction of that user. There are thus two methods to revoke user u data access:

The fast but incomplete method is to simply remove EPu(K) from the list of stored values. This will be sufficient to deny subsequent access from user u if that user is honest and did not keep a backup of EPu(K) (or, simply, a backup of K).
The thorough method is to generate a new master key K', decrypt all the data, reencrypt it with K', and encrypt K' with the public keys of all users except u. The database will then contain EPv(K') for all users v except u. This effectively locks out user u from any new data element.

The system described above can accommodate smart cards in lieu of "flash drives". There is not need for any entity other than user u to actually access the private key of user u.

Note: all of the above is about controlling read access to the data. Controlling write access, detecting alterations, duplications or suppressions is another matter.


Why is Gbt3fC79ZmMEFUFJ a weak password?

I was curious about the same thing, so I put Gbt3fC79ZmMEFUFJ into Google, and lo! and behold it found something that wasn't just a paraphrase of "Don't use this password" advice — the password itself was embedded in example source code that showed how you could send a password to a server! (link to page, and screenshot below)

So I think the real goal of that advice is not that Gbt3fC79ZmMEFUFJ is a mysteriously weak password because of the keyboard layout or because of low entropy or because it doesn't include symbols or Unicode or emoji or whatever:  It's simply to remind you that you should never use a password that's been published somewhere, especially one published as an "example" password!

[Update: This is intentionally a screenshot and not simply a code snippet; the content of the code is far less important than seeing how it appeared verbatim on somebody's website!]


Downloaded "DHL" fraud email to Linux, action needed?

This does not look like malware but "only" like phishing: the attacker tries to steal login credentials from you by claiming that these are needed to proceed. These kind of attacks are very common and try to phish credentials to login to various web mail accounts or whatever the gullible victim is willing to  enter in order to continue. I've got a lot of these mails myself.

Thus, while there might be also some malware inside the mail it is unlikely that you got infected since you only clicked on a HTML page attached to the mail (that's what I assume from your description) and you did this on Linux. While HTML attachments are also used to deliver malware this is usually done by embedding Javascript which downloads the malware from inside the page or rarely which embeds the malware directly. But these scripts then relies on Windows specific functionality (windows scripting host) to execute the malware and this does not usually work on Linux. It might maybe work if you are using Wine though to execute Windows programs in Linux but you probably need to have some really strange setup which makes HTML pages open with a Windows based browser instead of the Linux native one.

Of course, there might still be some attack going on which uses some previously only bugs and specifically targets Linux to delivers the payload. But unless you are a high-value target it is unlikely that such precious exploits are wasted on you, given that getting or creating this kind of yet unknown exploits is hard and can cost a lot of money.

To summarize: you are likely not infected. But maybe be more careful in the future anyway.


Minimum requirements for storing last 4 digits of credit card number?

Cardholder name, 4 last digits of CC number and its expiration date are all NOT sensitive data. The cardholder name and expiration date only require protection if you are storing them with the full primary account number, not the truncated 4 digit number.

If you are storing, processing, or transmitting cardholder data then you must meet all of the other PCI DSS requirements that kaushal mentions, but for the items you listed, you don't need to do anything special to protect them.

See pages 7 and 8 of the PCI DSS for more information on this:
https://www.pcisecuritystandards.org/documents/pci_dss_v2.pdf


Go on their website: https://cirt.net/nikto2-docs/options.html, and you will easily find how to specify output.

Inspiration for this kind of answer was a quote:

  If you give a man a fish he is hungry again in an hour. If you teach
  him to catch a fish you do him a good turn.


Is Payment using an iframe more secure than using as Javascript library?

Although the same-origin policy may stop an attacker from accessing the legitimate iFrame content, the problem is that the user has no way to verify that they're actually interacting with the legitimate iFrame (short of going to the source which most users won't do). An attacker could just as easily replace the iFrame source with a phishing page and gain the users credit card details that way.

Both iFrame and JS based gateways are vulnerable to approximately the same issues, so I would argue that they're both equally insecure compared hosted gateways. The benefits of hosted gateways are that:

The user can verify the URL to be sure who they're interacting with
The user can validate the SSL/TLS certificate and encryption to be even more sure about who they're interacting with
A payment gateway operated by a bank is most likely better tested for vulnerabilities than some arbitrary site.
Users can be reasonably confident in the integrity of their payment details if the totals, etc. are displayed by the external gateway. Compared to onsite where the site may say they'll charge you one thing then charge you another.

On the other hand, transferring users to an external payment gateway is considered a bad user experience and interfacing with a payment processor securely on the server side is complicated, so compromises are made and these JS based gateways are becoming popular.


Why should we use checkCallingPermission instead of checkCallingOrSelfPermission in Android?

The confused deputy is when you are operating on behalf of another program, but you do not appropriately check permissions.  The normal example of this is a grocery store cashier, scanning items using a barcode.  If a malicious customer changes the barcode, for instance putting a carrot barcode on filet mignon, and the cashier simply scans and charges carrot prices, he/she is being a confused deputy.  (On the other hand, if he/she notices, she's applying appropriate checking and is not a confused deputy, but a competent one)

In this case, what Fortify is saying is that you are being willing to substitute your own permissions for the caller's permissions (that's what checkCallingOrSelfPermissions does) - you are saying it doesn't matter what the caller can do, go with what you can do.

It is possible this is what you want - if your program is intended to perform privileged commands on behalf of unprivileged programs, this may be what you want. If that is that case, however, you are responsible for ensuring that the caller IS the real caller and that it isn't doing anything malicious.  Fortify can't help you there - that is where you'd do a real, intense code inspection and some serious testing to make sure that that trust-boundary cannot be exploited by anything malicious.  If your code passes, you'd normally then annotate so Fortify ignores it.  These are called trust-boundaries and they are where you want to spend a lot of analysis time to make sure that you are performing appropriate controls.

You probably want to just listen to Fortify here and make the change, unless you've done the work to verify your inputs and are positive that this call cannot be used to do something malicious AND it is the only way to do something useful.


How can I share files with other individuals using the cloud in a secure way?

If you are already settled on using Dropbox, then your only choice at the moment is to use a 3rd party program such as PGP (or free/open GPG) to first encrypt the file and place it into your drop box. I know you said you wanted to use public/private keys, but as an alternative, you could also use 7-zip to create secure archives with AES encryption based on a pre-shared key (password).

If you have not yet decided on Dropbox, you can look at similar online storage systems such as SpiderOak, Cryptoheaven, Mozy or similar, which perform client-side encryption of the files prior to uploading them into the cloud. You control the encryption key, and therefore the storage providers cannot access the data. I am not sure whether you can import existing private or public keys into those solutions or not, however.


Webservices exploitation / axis/services/AdminService?Method=AdminService

This looks like .NET WCF / WSDL service, you can access it with Visual Studio  but also any other WSDL client would work, but with this one you can actually access all objects, so you can properly hack it. It is created and debugged the same way:

http://www.youtube.com/watch?v=rrdpjrGojO8

Basically in this kind of service, you need to have SSL (HTTPS), Session (which is supported, but you need to make authentication) and Transactions (also supported).

It should not expose any objects or classes by default (in the XML you got with ?wsdl), but only login (authentication). You can wrap it in high level single object and encapsulate other methods to it, so it doesn't expose much, like getCommand().

It can also require certificate on the client side and firewall protection.

For hacking such services, there are not many useful tools, because it depends on how you code it, so you can get any WSDP / SOAP client and check it out yourself.


I believe that it is designed this way to circumvent technological limitations. Remember that the BIOS is written in a low-level programming language (Assembly or C), which are not object-oriented obviously. As such, assigning attributes to a signature or certificate that determine whether it is black- or white-listed is not an option. You can not just put them all together in a single 'database' (array, register) - there's no context. The only way to determine whether a signature/certificate is black or whitelisted, is based on the 'database' it is stored in.

That being said, there's still no clear need for two separate databases: you can block everything that is not in the whitelisted database - right? However, look at the below UEFI Secure Boot algorithm to determine whether an image shall be loaded or not (copied from the paper you referenced). You can see that an image which is signed with an authorised (whitelisted) certificate can still be denied if its specific signature is blacklisted... That is not something you could have accomplished by having only a whitelist and blocking everything that is not explicitly in there.


A quick Google search gave me this explanation.

  Setting first octet "02" actually sets the b2 bit indicating that the
  MAC address is locally administered. Looking at this MAC address thus
  indicates that the MAC address is changed by local machine
  administrator. But, its still good if you just want to hide your
  original MAC address instead of spoofing someone's MAC address.

  Another guess on why this works may be due to Windows Network Bridge
  feature. When you bridge 2 or more network adapters in Windows, the
  Network Bridge sets its MAC address to the first network adapter added
  to it with the first octet set to "02". Thus, if the network adapter
  drivers didn't allow the change, it would make the feature not work.

Source: TMAC Issue With Wireless Network & Workaround

So, I guess your best bet would be to use any Linux distro on VMware or VirtualBox and change your mac in that to whatever you want. Linux has no such limitation. :)


Long-lived SSL connections to dynamic IP addresses

If you have admin access to the users' systems you can start by dumping the list of open sockets and connected processes with "netstat -nab" on Windows or "netstat -nap" on Linux.  Just look for the source and destinations you are seeing in the proxy.  That may make it clear what is connecting.  You can also try connecting to the server side to collect its certificate.  The openssl s_client command is good for this.

openssl s_client -connect IPADDRESS:443 | openssl x509 -text

Hopefully it will be instantly clear if they are benign (Skype or other semi-legitimate traffic) or malicious (command and control channel) connections.


How to brute force a Java Applet in browser?

You are on the right path by downloading the applet manually and decompiling it, that's how I would approach it as well. You might just need more understanding of the code in order to reverse how it's downloading extra classes on the fly. Note that you don't need to run the app to understand how it works - the challenge is to retrieve so-called "rotor settings" which should be fairly easy to figure out from the decompiled classes.

You can also use a tool such as Charles Proxy to get around the HTTPS issue - Charles will give you a root certificate you need to install in the browser's trust store (and possibly in Java's trust store - on my Mac for example the Java preference pane has its own trust store), the tool will then intercept HTTPS and present valid server certificates signed by that root cert to the Java application. However I would be really surprised if this particular app is actually calling out any external service beyond its initial loading.

Worst case scenario, you could always just use the applet normally and use some automation tools like AutoIt to interact with it.

Good luck!


I will mark this question answered. If anyone is searching the answer for this question:

The p, q, g params are contained in the DSA certificate (in the DSS-Params field) along with the public dsa key (in the SubjectPublicKeyInfo field) - technically this is the server public key. These parameters, along with the secret key (private), are contained in the file produced by openssl dsaparam -genkey 1024 -out dsakey.pem.


Securely store basic auth credentials in database

One Solution

Addressing only the issue surrounding securely storing credentials. There is always a risk as the decryption key will still have to be stored somewhere.

For example, you could use OpenSSL to encrypt a string of text and then have that stored in the database on the "Insecure" Server. You'd have to use a reversible encryption method for this also.

Such a task could be accomplished with a simple PHP Script:

openssl_encrypt(PLAINTEXT, ENCRYPTION_METHOD, KEY, OPENSSL_OPTIONS, INITIALIZATION_VECTOR)

So in context, for example. (Ensure that you also add 16 bytes of padding before encryption and remove 16 bytes of padding on decryption, this can be removed by specifying specific OpenSSL options, however for ease, you can just add and remove the padding. Plus, this can also act as a degree of obfuscation, to a certain extent, in this example, 16 '=' characters have been used. This can also depend hugely on how your OpenSSL installation is configured, however, from personal experience, I always do just to be safe. Call it a touch of 'salt' if you would..)

openssl_encrypt("================username:password", "aes-128-cbc", "StRoNGeNcrYptIOnKey", 0, "16ByteIV--Random")

Running the above would produce something similar to:

+VUYZEh3FII7HRvJ8Qm8glERsgfsSKG9tE8Zyr2EJLL+9VaF7+41q/MeL8R1++L1

You can then run the subsequent decryption:

openssl_decrypt("+VUYZEh3FII7HRvJ8Qm8glERsgfsSKG9tE8Zyr2EJLL+9VaF7+41q/MeL8R1++L1", "aes-128-cbc", "StRoNGeNcrYptIOnKey", 0, "16ByteIV--Random");

Producing:

================username:password

There are a vast array of Encryption Algorithms that can be used. There is also a article on PHP.net showing how this can be achieved, and also includes Linux CLI examples, should you wish to do this via bash scripts also.

BEAR IN MIND

You will still have to keep a plaintext copy of the encryption key on your device if this is an automated process, which may not be ideal, nor would it be recommended. There is nothing to stop you using this approach and storing the encrypted data on your external server, however just take a moment to weigh up the security implications of storing a password in plaintext on a server.

If you're feeling neurotic

You could even encrypt the credentials once with one algorithm and then re-encrypt the cipher text with another, completely different algorithm.

Up to you, depends how secure the data is, and how much CPU time/justification/etc you want to dedicate to this.

Short Story

You need a reversible encryption solution if you want to be able to recover plaintext from cipher text and vice-versa.


So if I have your goals correct - you want to protect user data and you want their data to be recoverable if they lose their login password.

The basics: There is stuff you know; stuff they know; and stuff you both know.

Preferably for encryption of their data on your system to really make any sense, it needs to be protected by something you don't know - at least not all the time.

Putting aside password/account recovery for the moment, the simplest method is to only keep and match a salted hash of their password but cache their reentered password as temporary session data for decrypting/accessing/modifying their content while they are logged in. Discarding the session data when they log out or timeout.

Password recovery where serious data encryption is involved should be the user's responsibility, as hand-holding on this particular issue undermines the very security you are hoping to provide. Your website or application should provide backup options for their password, such as a QR code they can print out. Having this recovery option as a different password or credential doesn't really make any sense in this case as their data is only, at heart, encrypted by one symmetric key. You can also have a separate channel, credential or mechanism that is one-shot or email based for recovering their account but not their data. That distinction must be made clear to them. No password, no backed-up hardcopy - no data recovery.

The main concern of the initial approach you have outlined is that the roles and responsibilities of their data security is muddled. You should host their data in fashion useful for the website or app when they are logged in but they should retain the only credential to access their data. Bcrypt is a roundabout way of storing their data on your system without encryption; as all the information needed to crack it is already persistently on the server.

Naturally if the encryption/decryption occurs client-side then the security risk for the user is even less - but that depends heavily on how the website or app needs to use their data, so that may not be a practical option.


What useful things can I do with the html5 "keygen" element?

The obvious usage is client authentication. It can be used to improve security in combination with a passphrase or smartcard, or to be a convenient replacement for entering a password.

The WebID single sign on protocol is an interesting proposal in this context.

The main issue with client certificates is that it is bound to the browser. So if you are on another computer, you don't have access to them unless you took precautions.