Edit virtual host file using php I have a php application and somethings related to the application need changes to vhost.conf file.

Presently i'm making the changes manually. But i would like to automate it using a php script.

Is this advisable? I want to know the security complications involved.

Among the many reasons why I would not even think about doing what you're contemplating, these would be my Top-3:

Security:
I would never put any file that modifies a system's configuration file in a publicly accessible area. The reason is simple: the publicly accessible area is most vulnerable. If the file gets modded by someone (friend or foe), the modification could cause havoc to both your file system, as well as your server and/or system configuration.
Integrity:
PHP can (and probably will) mess up file locking. As a result, race-conditions might destroy your vhosts.conf file and break your server configuration.
Recovery:
Changes to vhost.conf need a server restart for the changes to be acknowledged by the server. You will need to think how you're going to handle that restart via PHP... and what happens when something goes wrong.  If your server crashes and takes down the PHP engine while it's at it (remember Murphy's law), how are you going to automatically recover from that? PHP won't be of any help in that case.


how common is it for an antivirus program to give false positive? Often antivirus programs trigger a false alarm that a certain file is corrupted or infected. My question is that how common is that and if it is too common, can we really rely on them.

Along with that, how easy it is to corrupt antivirus.

... Often antivirus programs trigger a false alarm that a certain file is corrupted or infected. My question is that how common is that

There are detailed tests at https://www.av-comparatives.org/testmethod/false-alarm-tests/.

The results differ between vendors and time but on average can be said that the higher the detection rate (true positive) the higher will be the more false alarms will be triggered (false positive). This is because only parts of the malware is detected by clear signatures, the rest is detected by heuristics which will never be perfect.

These heuristics (or machine learning models) are tuned by the vendor for some specific balance between false positive and false negatives rate. False positives will confuse the user. If there are too much the user will disable the detection completely. False negatives (malware not detected) on the other hand will have a serious security impact too. And models or heuristics can usually be tuned how much false positives and negatives they produce - only the less false negatives they produce (i.e. the more malware they detect) the more false positives they will also produce (i.e. the more innocent files will be detected as malware).

  ...  and if it is too common, can we really rely on them.

There is no true yes or no. If you mean with "rely on them" that you blindly believe the results then no. If you mean  with "rely on them" that the AV results are true in most cases then then yes.  You are not totally safe from malware if you install an AV (or use the existing AV built into Windows) but the average user is usually much safer than without an AV.

  ... Along with that, how easy it is to corrupt antivirus.

Not trivial but possible for a determined attacker with enough knowledge and time. In the past there were several cases of AV being vulnerable to code execution attacks, often due to errors in parsing (deliberately corrupted) files. This was especially bad since many of these AV did there analysis as system user. Bypassing AV instead by hiding the malware so that the AV cannot properly see it, is much easier though.


Does Intel or Arm support private key memory? I know some security processors have an isolated bus where you can store a private key and use it with hardware encryption without the key ever being stored in memory. Some even have key storage inside the SoC on an isolated bus so there's no possibility of stealing it even with physical access and a team of engineers. This feature is commonly used to implement HDCP, for example.

Question: I was wondering if there's some feature like that in consumer-grade Intel or Arm-based platforms?

I'd like to be able to write a key and use it for encryption with almost no chance it could ever be recovered.

Intel can do register-to-register encryption with the AES instructions and many ARM chips have crypto accelerators with similar functions.

There's two kinds of attack here: having an external DRAM bus physically snooped, and having a software exploit that sees the memory from the processor's point of view. The former is actually easiest to deal with by using on-chip RAM only.

Dealing with exploits is a problem, because the key has to be available to software at some point. The ARM solution is TrustZone, which is a sophisticated anti-compromise virtualisation-like mechanism that lets you have a secure microkernel on top of a much larger insecure OS. On the iPhone, the "secure world" is running the sel4 microkernel.

Write-only 'fuses' are used to seal the system once the chip is programmed to prevent JTAG access and unsigned updates. This is partly why the FBI attack on Apple is so serious: it involves forcing them to make an insecure version of the software that's signed with their keys.


Virus won't be picked up by Antivirus tools Today we found a virus / trojan on our network which has thus far:

Hidden all files and folders
Replaced the hidden files and folders with executables of itself, with matching icons, and renamed itself to those files.

Kaspersky picks it up, and is the only virus scanner we can get to pick it up so far. Process Explorer shows a boofa.exe running when we launch any of the fake folders.

Has anyone had any experience with this type of infection? Is there anywhere we can submit a file to Symantec or another virus company? We believe it's a 0 day attack.

Related information: We had user who had her computer "driving itself" hours after we found this virus. Someone took control of her computer, went to Walmart.com, bought a WOW game card and signed off.

Also we've run wireshark while running the virus on a quarantined computer but it makes no attempt to get out to the internet.

Symantec's virus submission portal:
http://www.symantec.com/security_response/submitsamples.jsp?inid=us_sr_flyout_contact_submit

I have seen this kind of infection before over the years in various forms.

Was the 'driving itself' computer the same as the infected one, or a different computer? If it is different, you will have to nuke all machines and start from scratch, I'm afraid. You have a RAT.


What actions should be taken by site according to Data Protection legislations? Many countries have data protection legislation:

Data Protection Directive in EU
Data Protection Act 1998 in UK
privacy laws in USA

Web application may have registration form where fields for name, surname, email address, address, phone number exist. What actions should be done by site if it stores such personal information? Should this information be encrypted?

Edit: I ask not about general industry best practices of building sites/protecting passwords. I ask about compliance with personal data protection legislation and standards/best practices in this area. Is presense of document called "Privacy Policy" a must for site that stores personal information? What information should exist in this Privacy Policy?

When talking about data protection laws the first thing to note is that they are laws so you should check with a lawyer if in doubt.

However, with things such as the UK laws (which you seem to be asking more specifically about) the guidance the information commissioner has on their website is pretty straightforward and nicely enshrines a lot of the principles that you'll find in other data protection laws in the EU (as the Data Protection Act is the enshrinement in UK statute of the EU Data Protection Directive).

http://www.ico.gov.uk/for_organisations.aspx

For the UK, there are a couple of quick pointers which you should consider (and there's more info on the website I mentioned. Here's the 8 "principles" that are set up by the act, shamelessly copied from the ICO's website.

  Personal data shall be processed fairly and lawfully and, in particular, shall not be processed unless –

  (a) at least one of the conditions in Schedule 2 is met, and
  (b) in the case of sensitive personal data, at least one of the conditions in Schedule 3 is also met.

  Personal data shall be obtained only for one or more specified and lawful purposes, and shall not be further processed in any manner incompatible with that purpose or those purposes.
  Personal data shall be adequate, relevant and not excessive in relation to the purpose or purposes for which they are processed.
  Personal data shall be accurate and, where necessary, kept up to date.
  Personal data processed for any purpose or purposes shall not be kept for longer than is necessary for that purpose or those purposes.
  Personal data shall be processed in accordance with the rights of data subjects under this Act.
  Appropriate technical and organisational measures shall be taken against unauthorised or unlawful processing of personal data and against accidental loss or destruction of, or damage to, personal data.
  Personal data shall not be transferred to a country or territory outside the European  Economic Area unless that country or territory ensures an adequate level of protection for > the rights and freedoms of data subjects in relation to the processing of personal data.


How reliable are device IDs provided by PhoneGap on Android and iOS? I have a web application that allows users to add mobile devices to their accounts (using mobile app).

Each device is uniquely referenced by its UUID. Mobile client is developed  using PhoneGap, so it uses device.uuid variable for this purpose. An app written in PhoneGap can be run on many systems, but my application targets Android and iOS only.

The question: How my system (both server and mobile client) should react, when it detect, that new user account (new login and pass) is trying to add a device, which UUID already exists in a database and is currently bound to another user account?

Can I assume (in today's world — on iOS and Android) that the UUID of any particular device:

is unique without any doubts (two devices can't have the same UUID),
is secure (can't be changed or spoofed).

In other words: Can my service automatically "rebind" particular device (UUID) to another user account, in situation described above? Can I assume that there are no two devices with the same UUID and there are no too easy ways on spoofing UUID?

Or should I introduce some "more secure" logic in such situations? Like some kind of device deregister (from first account) and re-register (on new account)? And dissallow user (user account) to add / register new device, if the same UUID is already registered with another user account?

I won't deny, I'm a layman in security subject. So, I would assume, that UUIDs are unique and spoofing-resistant enough to introduce mentioned automatic device (UUID) re-registration in mentioned situation.

No, UUID can be faked when reporting from a client.  Do not assume it proves anything about the identity of a device and do not assume that it is the same device as the last time you saw it.  If you really need to verify a device, the best bet is to make a certificate that you can store on the device and ask for that certificate when looking at it.

If they are genuinely reporting, they should be universally unique (what the UU stands for) but it is entirely possible for someone to force it to report a non-unique value of their choice in many (if not most) cases.  It can even be done with simple applications available on the app store on Android.


What conditions allow an attacker to write a cookie? Some CSRF protection mechanisms are vulnerable to attackers who can write cookies. Others are not but incur extra complexity or computational cost.

Help me understand the cost/benefit. What conditions enable attackers to write cookies for a domain?

One interesting scenario is HTTP vs HTTPS cookies. With an HTTPS site, man-in-the-middle attacks are not normally possible. However, if the user requests an HTTP site, a MITM attacker can tamper with the communication, include an iframe reference to the domain they want to target, and within the iframe write to cookies. Although this communication is over HTTP, cookies set here affect the HTTPS cookie store. I wrote about this some years ago.


How to determine the good number of PBKDF2 iterations according to technology evolution? I'm using PBKDF2 to derivate passwords but I never know what can be considered as a "sufficient" value for the iteration count.

Technology evolves very fast and I would also like to know how often and how much I should increase the value (eg: +20% every year).

There is no "sufficient" count, because user-chosen passwords can always be utterly weak, regardless of how well you coach them. You want the count to be the highest value that you can tolerate.

Remember that increasing the iteration count mechanically increases the operational cost. So you will have to set the count to a value which is low enough for your machine to still be able to process passwords in a timely manner. This is an analysis that you must make yourself, because it depends on your hardware and the expected peak load, and user tolerance to delays. Higher iteration counts tend to increase vulnerability to denial-of-service attacks.

You do not increase the iteration count on a regular basis to match "average technology". You increase the iteration count when you can afford it, which depends not on the general availability of faster servers, but on the servers that you actually bought and are using. Thus, you plan for an iteration count increase whenever you buy new hardware.


Can a user verify the quality/safety of pregenerated SSH moduli parameters? Many tutorials about how to mitigate the Logjam recommend regenerating Diffie-Hellman moduli.  This is a resource intensive operation, especially for high-bit groups.

This made me think if it made sense to build a small service offering moduli files for download, regenerated weekly or so.  OpenSSH offers a way to check the safety of the generated primes with the -T option of the ssh-keygen util, so a user should be able to verify that the primes are safe.  This takes significantly less time than generating a lot of candidates and and checking for safe primes in those.

Now my question is: is this procedure actually sufficient to verify that a foreign moduli file has not been "backdoored" somehow?  Could an attacker put specially crafted values in there, enabling them to break the key exchange, without a user noticing?

Thanks to @StackzOfZtuff for the linked articles.  Using those, this is what I've pieced together by now:

The generated parameters can probably be trusted as long as they are regenerated frequently.  For a higher security, one would have to check for reused parameters, which could be a sign that something fishy is going on.  It's still safer to generate parameters on ones own machine.

As the name suggests, safe primes work well when generating DH groups, as they guarantee a certain size of the resulting group.  So deliberately bad primes, resulting in reduced group sizes, are not a problem with the scheme described in the question.

The one possible attack I see is that the generating entity could chose specific groups and precompute as much as possible to solve the discrete logarithm problem using the natural field sieve.  This would make it a lot simpler for an attacker to break any DH using that group.  Naturally, the precomputation step is computationally expensive, so the attacker would want to reuse any broken group as much as possible.  This could be detected by keeping track of previous groups.

Instead of doing checks for recurring groups, just calculating one's own parameters is probably simpler.  Using DH parameters generated by others, without any nothing-up-my-sleeves guarantees, requires some trust in the entity providing those new groups, regardless of whether the underlying primes are safe or not.


What's the difference between SSL, TLS, and HTTPS? I get confused with the terms in this area. What is SSL, TLS, and HTTPS? What are the differences between them?

TLS is the new name for SSL. Namely, SSL protocol got to version 3.0; TLS 1.0 is "SSL 3.1". TLS versions currently defined include TLS 1.1 and 1.2. Each new version adds a few features and modifies some internal details. We sometimes say "SSL/TLS".

HTTPS is HTTP-within-SSL/TLS. SSL (TLS) establishes a secured, bidirectional tunnel for arbitrary binary data between two hosts. HTTP is a protocol for sending requests and receiving answers, each request and answer consisting of detailed headers and (possibly) some content. HTTP is meant to run over a bidirectional tunnel for arbitrary binary data; when that tunnel is an SSL/TLS connection, then the whole is called "HTTPS".

To explain the acronyms:

"SSL" means "Secure Sockets Layer". This was coined by the inventors of the first versions of the protocol, Netscape (the company was later bought by AOL).
"TLS" means "Transport Layer Security". The name was changed to avoid any legal issues with Netscape so that the protocol could be "open and free" (and published as a RFC). It also hints at the idea that the protocol works over any bidirectional stream of bytes, not just Internet-based sockets.
"HTTPS" is supposed to mean "HyperText Transfer Protocol Secure", which is grammatically unsound. Nobody, except the terminally bored pedant, ever uses the translation; "HTTPS" is better thought of as "HTTP with an S that means SSL". Other protocol acronyms have been built the same way, e.g. SMTPS, IMAPS, FTPS... all of them being a bare protocol that "got secured" by running it within some SSL/TLS.


Disable JavaScript on Firefox? I would like some further clarification on this topic.

Is there a way to disable JavaScript on Mozilla Firefox and still view the web pages correctly?
If yes, will this setting be enough to hide the real IP in case the VPN drops when passively viewing a web page?

Is there a way to disable JavaScript on Mozilla Firefox and still view the web pages correctly?

No. Because lots of web pages need JavaScript.

  If yes, will this setting be enough to hide the real IP in case the VPN drops when passively viewing a web page?

No. There are other techniques that could be used to leak your IP in this case - such as an iframe with <meta refresh>. Although, they're far less common.


How can disabling Diffie-Hellman cipher for packet inspection be secure? I have noticed that a number of network packet monitoring tools on the market today seem to have roughly the same recommended configuration parameters as described below:

Disable Diffie Hellman in Apache

Essentially they claim that network monitoring of Apache or IIS cannot work for TLS traffic unless the Diffie-Hellman cipher is disabled in Apache.  What confuses me is how this does not end up breaking TLS in that instance?  How does key exchange still securely occur in this case?

If Apache uses a different asymmetric cipher suite for key exchange for example, then what exactly does disabling Diffie-Hellman provide for the monitoring tool here?

TL,DR: using this product strictly as recommended most likely violates your compliance rules. This is not because of the Diffie-Hellman aspect, but I still wouldn't use it, partly because the DH aspect demonstrates an insecure architecture and partly because other aspects of the documentation demonstrates an awful lack of concern for security.

There are several different ways a TLS handshake can work. Considering the common case where the server is willing to talk to anyone, but the client wants to talk to a specific server, the handshake has two functional goals:

Allow the client to verify that it's talking to the intended server.
Allow the two parties to agree on a session key (the key exchange part).

The key exchange has a security goal, which is that a man-in-the-middle who is capable of observing and modifying the communication cannot impersonate the server or obtain the session key.

The server first sends its public key to the client, plus some additional data (certificates) which allow the client to verify that the public key is the correct one for this server, thanks to PKI. At this stage, the client knows the public key of the legitimate server (or else it detects that it's been sent a fake key and closes the connection), but it still can't trust what it receives since an attacker might have modified the data.

After this, there are three ways to go. (See also What key exchange mechanism should be used in TLS? for a more technical discussion.)

Encryption: the client generates a session key and encrypts that with the legitimate server's public key (confirmed by PKI). Only the legitimate server can detect it, a man-in-the-middle can't, because it doesn't have the server's private key. This happens with ciphersuites that have RSA in their name but not DHE. Apache's category RSA designates these ciphersuites.
Signature: the client and the server use a Diffie-Hellman to exchange data in such a way that both sides are able to calculate the same session key, but a man-in-the-middle cannot find the intended session key. A man-in-the-middle attacker may be able to modify the data to cause the two sides to calculate different session keys that the attacker knows, however. To avoid this, the server sends a signature of the data exchange during the handshake, in such a way that when the client verifies this signature, it knows that the server used the same data to generate its session key. The attacker cannot fake this signature because it doesn't know the server's private key. This happens with ciphersuites that have DHE in their name (including ECDHE). The E in DHE stands for “ephemeral”, because the Diffie-Hellman algorithm is used to generate a single-use session key. The signature part may be RSA or ECDSA. Apache's category EDH designates these ciphersuites.
Key exchange: there are ciphersuites that use static Diffie-Hellman private keys, but basically nobody uses them so I won't discuss them any further.

Now consider what happens if the attacker can observe the traffic but not modify it, and additionally knows the server's private key. With the first method, they can decrypt the packet containing the encrypted session key. With the second method, they can't do anything. An active attacker who knows the server's signing key can impersonate the server during the handshake, which leads to a valid TLS session between the server and the attacker and another valid TLS session between the attacker and the client. But an attacker who can't or won't modify traffic can't do this.

This property of the second method is called perfect forward secrecy (PFS), because if the attacker manages to record traffic and then later manages to obtain the server's key, they still won't be able to decrypt the recorded traffic. They'd need to know the secret parts of the Diffie-Hellman key exchange, but the participants erase them as soon as the handshake is over.

That middlebox apparently wants to monitor the traffic that the server is serving, but not actively forward it. It would need to know the server's private key, otherwise the whole thing is pointless. So the instructions are to disable all the ciphersuites that use ephemeral Diffie-Hellman, i.e. all the ciphersuites with PFS, and keep only the ones RSA-encryption ciphersuites.

This is a terrible way to monitor traffic, because it's degrading security. PFS is not needed to ensure the basic security of TLS, but it is a good thing since it limits the impact of a compromised private key. In particular, a private key becomes useless once the corresponding certificate has expired or has been revoked (assuming that clients correctly check for expiration and revocation). Without PFS, a leaked old backup allows decrypting old traffic. Additionally, this setup requires copying the server's private key to another box, which increases the risk that the private key will leak.

The proper place to monitor traffic would be on the server itself, between the application and the TLS endpoint. I guess this product is designed this way because it makes deployment easier, but it's a terrible design.

In addition to disabling PFS, those instructions enable export ciphers, low-security ciphers such as single DES, and SSLv2. I don't know how old this product is, but even in 2005, which is when Apache 2.2 and RHEL4 (mentioned on the product's web page) came out, all three were obsolete, to be enabled only if you really absolutely had to talk to ancient clients. Enabling any of those three today would violate any cryptographic compliance standard.


Someone is using my (or has the same) email I just got a letter from court saying I made 49 threats to someone I had a problem with three years ago. This person presents "my emails" as evidence. I went through all my emails, and I haven't found a single one. The mail presented as evidence all come from my email address. He asks for 20,000 dollars for moral damage!
How can this happen?

(ed. The letter is a valid and official legal document in accordance with the normal procedures in the country of Portugal. OP has already engaged with a lawyer. The accuser is a known scam artist. This question is about the technical details of the emails.)

Is it a scam?
First of all, make sure that you actually got the letter from a court. This might very well be a scam - it sure sounds like one. Do this to verify that the letter is real:

Make sure that the name of the court correspond to a real court.
Find contact information to that court through some independent method (i.e. not using any information in the letter).
Contact them and ask them if they did in fact send the letter.

If it is not a scam
If it is not a scam, I see three possibilities:

The person accusing you of the threats never received the emails, and have forged the evidence. That would not be hard to do. (An investigation of the email headers will not help here, since they can also be forged.)
Someone has spoofed your email address, and has sent emails that appear to come from you. This is by no means impossible. (An investigation of the email headers could be useful here.)
Someone has hacked your email account (perhaps you used the same password on a site that was breached), sent the emails, and then deleted all traces (e.g. removed them from the sent items folder). (An investigation of the email headers would not help here, since the email is in fact sent from your address. Access logs from your email provider could prove useful, though.)

If it's not a scam, what you need to do in any case is to get some legal advice.


General Purpose Hybrid Encryption File Format With hybrid encryption, a symmetric key is generated and used to encrypt the plaintext. The symmetric key is then encrypted with a public key. The payload consists of the ciphertext plus the encrypted symmetric key.

I've come accross a number of different methods for storing the ciphertext+encrypted key payload. one option is to use Json key/values for the base64 encoded ciphertext and encrypted key. Another option is to simply concatenation the ciphertext and encrypted key. PGP also uses a hybrid encryption and has its own file format.

Is there any standard data/file format for storing the result of a hybrid encryption operation besides PGP? It seems like such a format would encourage interoperability.

Yes, there are other standards, including the original RSA PKCS#7, its successor CMS (sometimes also referred to as PKCS#7), and the related S/MIME which is used in email.

However OpenPGP is more "general purpose" than any of these and is designed with useful features in mind such as sophisticated key management, configurable ciphers, and compression, among other things. You aren't going to find anything much more general purpose than that.


I need assistance in properly understanding the IA-7 control in NIST SP 800-53 I've recently been working on a number of A&A tasks for the RMF for a US Government entity, and I'm having a hard time properly understanding the IA-7 control of NIST SP 800-53 and the supplement guidance and 800-53A isn't providing me the clarity I require.  For reference, this is the Control Description for IA-7:

  The information system implements mechanisms for authentication to a cryptographic module that meet the requirements of applicable federal laws, Executive Orders, directives, policies, regulations, standards, and guidance for such authentication.

Specifically, I'm having a hard time wrapping my head around what "authentication to a cryptographic module" entails.  How does one authenticate to a module as opposed to simply have the necessary access rights to the module on the system?  For a bit of background, we primarily utilize openssl, but we also leverage urandom and pgcrypto.

Waking the zombie at my own peril and for the benefit of people looking to understand this control.  I did a fair amount of research on the subject and was able to find a pretty definitive answer.  Stay with me because it isn't short, but it's pretty definitive.

As best I understand it, if you are an implementor of a cryptographic control module that provides an authentication mechanism or if your system provides access to a cryptographic control module that provides authentication then you must meet the authentication requirements "...of applicable laws...standards..." etc.  This reference is calling out the requirements in FIPS 140-2 which refer to a human operator interacting with a FIPS 140-2 compliant cryptographic control module.

  4.3.3 Operator Authentication Authentication mechanisms may be required within a cryptographic module to authenticate an operator
  accessing the module and to verify that the operator is authorized to
  assume the requested role and perform services within that role.
  Depending on the security level, a cryptographic module shall support
  at least one of the following mechanisms to control access to the
  module:

  Role-Based Authentication: If role-based authentication mechanisms are
  supported by a cryptographic module, the module shall require that one
  or more roles either be implicitly or explicitly selected by the
  operator and shall authenticate the assumption of the selected role
  (or set of roles). The cryptographic module is not required to
  authenticate the individual identity of the operator. The selection of
  roles and the authentication of the assumption of selected roles may
  be combined. If a cryptographic module permits an operator to change
  roles, then the module shall authenticate the assumption of any role
  that was not previously authenticated.

  Identity-Based Authentication: If identity-based authentication
  mechanisms are supported by a cryptographic module, the module shall
  require that the operator be individually identified, shall require
  that one or more roles either be implicitly or explicitly selected by
  the operator, and shall authenticate the identity of the operator and
  the authorization of the operator to assume the selected role (or set
  of roles). The authentication of the identity of the operator,
  selection of roles, and the authorization of the assumption of the
  selected roles may be combined. If a cryptographic module permits an
  operator to change roles, then the module shall verify the
  authorization of the identified operator to assume any role that was
  not previously authorized.

...so that's what this rule is talking about.

This control is only applicable if you're providing authentication to the cryptographic module for purposes of managing the cryptographic module.  Evidence that it is not applicable in other cases can be found in a STIG (although not easily)...

https://www.stigviewer.com/stig/application_security_and_development/2018-09-13/finding/V-70159

  Details Check Text ( C-70635r1_chk ) Review the application
  documentation and interview the application administrator.

  Identify if the application provides access to cryptographic modules
  and if access is required in order to manage cryptographic modules
  contained within the application.

  If the application does not provide authenticated access to a
  cryptographic module, the requirement is not applicable.

  Review and identify the cryptographic module. Refer to the NIST
  website listing all FIPS-approved cryptographic modules.

It seems like an uncommon use case in the private sector but may be more common in government sectors like DoD.


IPC Security on Server An application is running in a customer's environment on a single server and consists of a collection of Windows Services that communicate with each other using (unencrypted) TCP messages.
Although these messages can't be viewed across the network, I am conscious that someone could theoretically run a tool like Wireshark on the server and view the content of these messages. Is this a serious enough risk to warrant updating the application to encrypt these messages? Or is there another - possibly simpler - to protect against this threat?

If a user is able to install and capture packets with Wireshark, they must already have administrative privileges. If a user has administrative privileges, they can likely already tamper with your application in other, more serious ways.
If you don't want a user to have the ability to tamper with your application, do not give that user administrative privileges.


Difference between KMS and PKI While the PKI System deal with digital certificates life cycle
and Key Management System (KMS) deal with keys life cycle.

What is the the fundamental difference between them?
Is it possible to consider KMS is a PKI system without CA?

KMS can manage certificates.

What happened to the RootCA for this certificates?

You are getting hung up on the "life cycle" terms and not looking at the big picture.

PKI is a concept. It is the infrastructure for the idea of public/private keys along with the processes and protocols to make it work. It introduces the idea of a CA along with defining their responsibilities.

KMS is a product. It answers the question, "what do I do with all these private keys I have from the CA?"

PKI has protocols and guidelines for dealing with certificate life cycles, but a KMS actually implements life cycle management for specific keys for a specific organization using PKI standards.


sudo -u   vs sudoedit I have read on the internet that you have to use sudoedit instead of sudo vim. I understand why this is and should be used so you can't just edit root-user files.

However I would like to manage a nologin user (service account that run a single application) let's call her 'nologinuser' with my own non-root account. For this I would need the correct rights in the sudoers file.

I have been in discussion with 2 Linux system managers and both disagree.

Linux admin A says: you should create a sudoedit rule for every config file and a sudo rule for every command.

Linux admin B says: Just create a sudo rule that allows you to read/write/execute everything as that user with "sudo -u nologinuser *"

Personally I agree with admin B because with "sudo -u nologinuser " you can execute every command as that user only, and through this command you also inhered that user his rights because you execute it as that user. This would also not cause a security issue in the ability of changing root-user files because nothing is done as root and it is most flexible.

Who is right, or is there a third better option? Who can tell me the best practice in this. What is the best way to manage a nologin application user as non-root?

Thank you.

It depends what are your exact needs.

Solution A: This is the preferred one when executing commands as a privileged user (maybe root, maybe another account which has more privileges than a standard user). This allows to define a policy describing the exact actions to be allowed, so that this access cannot be abused by the unprivileged user (either maliciously or mistakenly).
Solution B: In term of privileges it is strictly equivalent to providing you an interactive shell as nologinuser (with a better audit and password management than actually giving you the target account password).

As per your message, I have the impression that there don't seem any real problem in handing you a shell as nologinuser, flexibility however might be an issue (you don't want to have to call the admin each time you want a new command, option or file added to the sudoers file), and your main concern is that no action should be done as root.

If my understanding of your message is correct, I would go for the solution B.

You are right in your conclusion that allowing user_1 to execute commands as user_2 using sudo does not provide any root privileges to user_1, either directly or indirectly.

People often have the wrong impression that sudo provides super-powers. While its most common use is indeed to run commands as root, it can also be used with the reverse effect to decrease the privileges of a command.

Personally I often use sudo to execute a command as a lower-privileged user (a daemon, a file-transfer utility, etc.). In such cases there is no point in restricting the executable commands, just define which users can run command as this nologinuser and under which conditions (password required or not, environment variables to keep, etc.) and you will be fine.


Is an AJAX call less secure than the normal POST method? I currently have a standard login form like this:

<?php
if( isset( $_POST['username], $_POST['password'] ) ) {
    // escape both strings and compare them to database
}

?>
<form action="" method="post">
    <input type='text' value='username' name='username'></input>
    <input type='password' value='password' name='password'></input>
    <input type='submit' value='submit'></input>
</form>

I want to move to AJAX, so the new page doesn't refresh. This is my new method:

<script>
function login_ajax() {
     var formdata = new FormData();
     var ajax = new XMLHttpRequest();
     formdata.append('username', document.getElementById('username').value;
     formdata.append('password', document.getElementById('password').value;
     ajax.open( "POST", "https://my-website.com/login_validation.php" );
     ajax.onreadystatechange = function() {
         if(ajax.readyState == 4 && ajax.status == 200) {
             // do something
         }
    }
    ajax.send( formdata );
}

</script>
?>
<form action="" method="post" onsubmit='login_ajax(); return false;'>
    <input type='text' value='username' id='username'></input>
    <input type='password' value='password' id='password'></input>
    <input type='submit' value='submit'></input>
</form>

And my login_validation.php looks like this:

<?php
if( isset ( $_POST['username'], $_POST['password'] ) ) {
    // escape strings compare to database and sign on

}

Is the second method less secure than the first?

They are both equally secure. There are mistakes you could make in any version, but none is inherently better than the other.

What is relevant for the security of your login is the server side. You can put no security restrictions on the client, since any such restrictions could be trivially bypassed. So the important thing here is the code on the server side doing the validation. And that's the same for both options here - it checks that it's a POST request, and check if the username and password are correct.


Java application run as root I'm testing Linux server where Java web application is run as root, I typed:
>ps aux
in the result I see:
root     18265  (...)  Sl+  19:52   0:37 java -Xmx2g -jar test_app.jar
what is the best explanation for admins to convince them to run application not as root?
What if user is not root, but in sudo group?

If there is an exploit in that program that allows for remote code execution, I as an attacker could trigger that vulnerability to run code as the root user. If I can take actions on behalf of root, I own the machine. I can do whatever I want on that device. I can view, modify or delete any file I choose. Any connections that machine has to other applications, I can leverage to then move laterally across the network. The root user is the highest privilege level, and should be protected for this reason.
If that java app is instead run as the user user, and user has sudo permissions, that would still be much more secure than running the app as root. In this case, if I were to exploit a vulnerability that allowed for RCE, I would only have the permissions and access that user has. I wouldn't be able to run sudo to escalate to root without the password for user, the hash of which is hidden away in /etc/shadow (a file that only root can read). So after the initial foothold on the linux machine, I would have to find a privilege escalation vulnerability to exploit in order to get root privileges. This adds a layer of security which helps to prevent high impact compromises.


Directory transversal in PHP with the $_FILES array? I'm working on a php application that is handling file upload.
I'm trying to inject a path transversal payload in the filename such as /../../../../etc/.

The thing is that the vulnerable line of code is using the filename through the $_FILES["name"] array. This built-in php array is doing an automatic sanitization on all the vulnerable special characters.

I was wondering if that is a sufficient protection or if we need to add some other sanitizations? Is there a way to bypass php sanitization?

According to my experience, $_FILES["uerrfile"]["name"] already consists of only a filename part, with the path stripped out.

However, the PHP manual suggests to use the basename() function anyway, so I am it no position to tell you otherwise.

On a side note, I wouldn't advise to use the original filenames anyway as they are highly inconvenient to handle, given they could be duplicated, or contain special characters, or be too long and get truncated, etc.

So a new name assigned by a system would be more usable. Personally I developed a habit of naming the files after md5() from the file contents, or you can use any other method such as uniqid().


Can the Windows lock screen be attacked with software? As a follow-up to this question, I am wondering how much care I need to put into my Windows login password, for when I leave my computer alone in "sleep" mode. (I know that Windows passwords can be easily removed.) Is there any software that can try to crack the password from the lock screen? Or do I just need to have a login password that cannot be defeated in, say, my hour-long lunch break?

There is a related question about the Windows screen saver password; I would guess that the lock screen is controlled by different logic.

You ask about cracking, a long and complex 15+ length password will render crackers useless within your timeframe. This bypass method takes 15 minutes at most:

You can disable autorun, you can put a password on your BIOS.
But a single BIOS reset (requires 2-5 minutes of unmonitored physical access) will remove the BIOS password, allowing an attacker to BOOT the computer through USB/CD with e.g. KON-BOOT. This attack will temporarily allow any password with your accounts without resetting your old password.
The only protection from this that I know of is system encryption e.g. VeraCrypt.


How to find encryption method? How to find encryption method if both encrypted and decrypted code known?

j1RSfCKUuvqjHLBtuIe9AOb03gkd2ENLj+KNkWUHff6duf1/iz2zNjU48B0v4O3PFWV3Q0scOPYDu7vuW2mvNKJWXQrIpHGCBEeqyXpihR1WWQo6hfe81YenVH35Gxp/7Xmltp5V8+XEhXOV8jyXtjBaKGVNgmA6F5kmQPAqCaA=

this is a sample encrypted code, how could i identify its method if i know original code?

Depends on how many plaintext-ciphertext pairs you can collect. Potentially, you can infer what mode (e.g. maybe ECB) is used.

On most occasions, though, known plaintext attacks (KPA) are weak against properly designed ciphers as those are designed specifically to thwart at least that type of attacks. This means that collecting and comparing the pairs would yield no information as to which cipher and the encryption key were used to encrypt the text.

So sorry, unless it's a simple XOR with constant keystream, you are unlikely to find out the exact method used with only one text pair.


How to achieve non-repudiation? If I have a message that I need to send to another person, how do I achieve non repudiation ?

Is digitally signing the message sufficient ?

No.  Digital signatures are not sufficient for non-repudiation -- not by a long shot.
Non-repudiation is a legal concept.  It means that, if there is a dispute, in a lawsuit it will be possible to hold one party to their commitments.
For example, mathematical schemes that claim to provide non-repudiation have to withstand the "jury attack".  Some expert witness is going to have to be able to explain, in non-technical terms that an ordinary juror (and judge) can understand, why the mathematics proves anything at all.  Meanwhile, an expert witness for the other side is going to be arguing the opposite.  If the scheme uses fancy mathematics, it is likely to be incomprehensible to the jurors and the judge, and hence not likely to be of much use in a lawsuit.  This is a kind of attack that most mathematical schemes in the literature are unlikely to be able to stand up to.
I'm afraid much of the cryptographic research community has screwed this up.  Researchers have written many technical papers that claim to address "the non-repudiation problem", trying to solve it with mathematics -- but what they've failed to accept is that there is a tremendous gap between the crypto-mathematics and the pragmatics and legal issues.  And unfortunately, the hardest part of the problem to solve is not the mathematics, but rather the pragmatics and legal issues.  Unfortunately, this seems to be a long-standing blind spot within the cryptographic research community.
Here are some of the challenges to achieving true non-repudiation that a court or lawyer would be satisfied with:

Malware.  What if Grandpa's computer is infected with malware, which steals his private key?  Are we going to hold him responsible for anything signed by that malware -- even if it means he loses his house?  That'd be ridiculous.  In particular, an easy way to repudiate is simply to claim "my private key must have been leaked/stolen".
Similar remarks can be made about social engineering.  When social engineering attacks have a good chance of being successful at stealing the private key, and when the scheme is designed in such a way that ordinary people cannot use it securely, and when the designers know (or should have known) this, I think it is questionable whether jurors will be willing to hold Grandpa responsible, simply because he got screwed by a poorly-designed security system.

Humans vs. computers.  Legally, non-repudiation is about the actions of a human.  A court is going to be looking for evidence that a human (e.g., Grandpa) assented to the terms of the contract/transaction.  The cryptographic schemes cannot achieve that.  They can only show that some computer performed some action.  Cryptographers like to assume that the computer acts as an agent of the human and the computer's actions can stand in for the human's actions, but this is not a reasonable assumption.  For example, malware on the person's computer can apply the private key without the human's consent.
Basically, most of the cryptographic research into non-repudiation schemes has the wrong threat model.  It is based on assumptions that we've since discovered are faulty.

If you'd like to learn more, there has been a great deal published on these gaps between what's called "non-repudiation" in the cryptographic literature vs what lawyers would accept as adequate.  Here are some example publications where you can read more:

Carl Ellison, Non-repudiation.

Ross Anderson, Liability and Computer Security: Nine Principles.

Brian Gladman, Carl Ellison, and Nicholas Bohm, Digital Signatures, Certificates and Electronic Commerce.

Adrian McCullagh and William Caelli, Non-Repudiation in the Digital Environment.

Michael Roe, Cryptography and Evidence.

Peter Gutmann, Digital Signature Legislation.

Greg Broiles provides a legal perspective on non-repudiation.


How can a DLL be loaded during run time? I'm new to malware analysis. I was following through this lab :https://jmprsp.wordpress.com/2016/03/06/practical-malware-analysis-ollydbg-lab-9-03/

I observed that the DLL loaded before and after run time are different. May I know how is it possible to load a DLL only during run-time?

"DLL" means "Dynamic-Link Library".

Its whole purpose is to be loaded at runtime, to provide the symbols (essentially: function names) that an application uses from the library.

So, you simply supply the run-time linker with your DLL, and supply the linker at compile-time (link-time, to be exact) another one. The only thing they have to agree on is to contain the same symbols.


Is PHP loadXML vulnerable to XXE attack (and to other attacks)? Is there a list of vulnerable functions? I have PHP code that uses the loadXML function (as well as other XML functions).

Is the loadXML function vulnerable to XXE attack? Namely, if the XML contains external entities, will they be interpreted?
Is this function vulnerable to other XML based attacks? E.g., the Billion Laughs DoS attack?
Can you refer me to a list of functions that are vulnerable to XXE and to other XML-related attacks?

I know that it is possible to easily block XXE attacks in PHP by changing the settings. Yet, I will be glad to get answers to the questions I raised.

Is the loadXML function vulnerable to XXE attack? Namely, if the XML contains external entities, will they be interpreted?

By default, no.

External Entities are not parsed without LIBXML_NOENT being set. If libxml_disable_entity_loader is set to true, not even LIBXML_NOENT will allow XXE.

  Is this function vulnerable to other XML based attacks? e.g., the Billion Laughs DoS attack?

No, billion laughts will be caught with default settings:

DOMDocument::loadXML(): Detected an entity reference loop in Entity

What will not be caught is quadratic blowup. Note that the entities need to actually be substituted, which is either done via the rather poorly named LIBXML_NOENT or by simply accessing the node (eg via  textContent).


Are there remote exploits that are easier to perpetrate than installing a keylogger on a standard win10 laptop? I'm trying to improve my wife's password hygiene, and have now finally got her to use different passwords for different sites. She now has trouble remembering to keep the book of them to hand. She flatly refuses to learn to use another program, like KeePass (Excel, Zoom and a web browser are pretty much her limit).
Even using a password manager, malicious installation of a keylogger would be game over for bank details and the like.
System and use. ADSL router with its standard 'firewall', wifi to several machines including her win10, with the standard Microsoft Security running on it, updates accepted when offered, but no third party antivirus. No illegal or even unusual browsing done on it, it's just used for online shopping, banking, facebook and zoom. It doesn't leave the house, and doesn't get used with random USB sticks. She seems reasonably savvy about phishing, and often asks for my approval before opening emails. I am the only admin user on it.
What exploits could access a simple unencrypted notepad file of passwords on her machine? How much more dangerous is that to have than an encrypted file or a password manager? The only one that springs to mind is having the machine stolen or lost, unless it's possible to remotely access files without actually installing software.

Keyloggers and the like are not "exploits", but are merely malicious programs that may execute as the payload of an exploit or after tricking the user into running them.
But you seem to have identified the problem; if there is malware on the computer, it could read the text file containing passwords. If the password file is encrypted, it could likely just steal the password with a keylogger, or grab the unencrypted database out of memory. Everything on a compromised computer should also be considered compromised.
It depends on a lot of things, but the most likely vector for a home user is probably downloading and executing untrusted programs, which could access all of your user data, or even take over the entire system if granted administrative privileges.


How can one encrypt a file and be sure the original file can not be recovered on a SSD? Let's say that I have an unencrypted file and I'm trying to encrypt it and make sure the original file can not be recovered from my disk. If I, for example, create an archive, put the file into it and encrypt the archive it seems pretty obvious that even if I delete the original file it is still on the disk and can be recovered. From my understanding, if the file is on a hard disk, the original file can be overwritten and at that point data recovery should be practically impossible.
But as I understand with SSDs, this gets a bit more complicated. Since SSDs employ wear leveling, even if I were to overwrite the original file, it may not be written to the same physical location and therefore there is a significant enough chance it could be recovered.
So how can I securely encrypt files on a SSD?
By the way, the archive scenario I described earlier is just an example. From my understanding this problem should affect all encryption tools.

The best option is to use full-disk encryption that encrypts everything whether it's explicitly encrypted with file encryption or not.
In your situation, you could try and write a file so big that it fills the whole drive, making it more likely you overwrite the original file. However, there could be data from the file written in paging (swap). You might also be able to enable full-disk encryption on-the-fly; this depends on the capabilities of your operating system.


Ransomware left some files not encrypted A ransomware attack happened to my server, I've backups and all and I tracked down the reason to two elements (either unupdated Bitnami LAMP stack or unupdated Flask server) but I noticed some files aren't encrypted, any checks I should do to verify that I can use this files safely?

The way ransomware encrypts files is based on extensions. They add a broad range of extensions to cover the majority of crucial files for working/business/school and so on. That list is not dynamic or cloud/service based, it is usually hard coded into malware itself. At least that's what happened up until now. So if for example, ransomware didn't add .mp3 to the encryption list, it would be skipped, the files would not be affected. You can do a full scan with anti-malware and anti-virus software just to be sure, but I think the data will not be affected and you can use them safely.

Fun fact: This is why having 2 ransomware (One after another) on your computer will not do additional damage. Usually, ransomware doesn't contain other encryptions extensions.


Why don't websites provide a checksum of their downloadable files? I very rarely see websites provide a SHA-2 hash that's signed to ensure file integrity for the user downloaded side file, and show that the file has not been manipulated or out right replaced with a malicious version, such as the incident that occured with CCleaner last year. The only recent ones I've seen provided are Jetbrains products and KeePass, and you had to scroll pretty far to find it tucked under the page.

Edit: Like the Certificate Authority, can we not have a Hash Authority which signs the hash that the company provides for their product so the issue of a server takeover would be mitigated dramatically?

You mention CCleaner, so it is relevant to link to Would a digital signature have prevented the CCleaner compromise? The short answer is that it would not have prevented this particular compromise.

This gives us our first problem with providing hashes: Who are we trusting to sign the build, and what are we trusting them to check? Does the signature simply represent the official build server, which could be compromised? Or does it represent an actual security audit by some pre-trusted party?

However, there are other attacks that such a hash would guard against - for instance, a compromised or fraudulent mirror offering a tampered build. In this case, it would be enough for the primary project page to publish a hash, which could be verified against the download offered by any mirror.

However, this leads us to the second problem, which is one of the hard problems of cryptography: key distribution (or, in this case, signature distribution).

For an unsigned hash, you are simply trusting the page that displays that hash not to have been tampered with. A signed hash at first sight seems better, but you still have to download the public key from somewhere, so you are still trusting the source of that key. If an attacker can direct a user to a fake download page, they can add a link to a public key of their choosing, and the user will get a false sense of security by verifying the hash of a compromised download.

The alternative is to have some central authority that you trust for multiple different applications - this is the principle behind Windows driver signing, Linux package managers, and phone app stores (and also behind the certificates used for HTTPS websites). Now you have a new problem: why do you trust those central authorities? Are they directly auditing the source code and build processes of the files you're downloading? Or are they delegating the trust, via a counter-signed certificate, based on some assurance from the party actually producing the software? Plus, you still need to acquire the root public key somehow - presumably it was included in some trusted installation media when you installed the OS / app store / package manager.

In the end, publishing a hash will be most useful for large projects, where:

the same user is likely to download and verify multiple versions, or different applications, with the same public key;
and, the source of the public key is likely to be different from the server offering the download (a different server, or some physical medium)

But even then, it cannot fix all exploits, as CCleaner demonstrated; and there is a danger in giving users a false sense of security.


SRP, or hash hashes over HTTPS? I'm designing a web API, which will use credentials from another system to authenticate. The API will require HTTPS, however I still want to avoid sending a basically plaintext password over the wire using HTTP Basic Authentication.

I'm aware of the Secure Remote Password protocol, but TLS-SRP (as SRP authentication over TLS will effectively be) seems overkill for the level of sensitivity of data the API will provide (mostly sensitive business-level IT info; not something we want to shout to the world but not financial or personally-identifying).

I'm thinking that a scheme where the client SHA256-hashes their password, then transmits username and hash over HTTPS to the API server, which can then bcrypt it before comparing to a stored hash, should be more than enough to securely transmit and store user credentials. What vectors could this be vulnerable to (other than a keylogger on the client device)?

So I'm going to call your hash a payload.

Your idea sounds like:

  Send me a payload so I can confirm the bcrypt value of it.

Which exactly the same as a password:

  Send me a payload so I can confirm the bcrypt value of it.

This is nothing more than security theater and you're trying to get people to generate an absurdly long password they then need to store and reuse every time because they may not be able to regenerate the exact same way.

You've also already said that if someone completely owns the user in a MITM attack it's kind of worthless because now they have to generate a new hash, for this service and any other service that uses that hash(just like a password).

Really what you're asking as user to do is generate a unique, HUGE, impossible to remember password for your service that they have to store anyways, now in a digital only format because it's impossible to type, or write down.

This is a BAD idea. This also ignores the limitation of bcrypt only using the first 72 characters of a string.


Protecting emails in your database It's common to encrypt passwords in the database, but I'm wondering what solutions are out there to protect emails in your database.

Not just from hacking, but from disgruntled employees or engineers losing a laptop with a copy of the database etc.

Unlike the password, we'd need to get the original email out periodically (so a two way encryption would probably be necessary) but we also don't want emails sitting around in the clear, or accessible from admin interfaces with employees all over the world.

For example - we hire salespeople all over the world, and as part of their job they need to email customers.  Also if a customer emails support we need to match their account by email.  But we also don't want salespeople or customer support staff to be able to scrape a list of a million custom emails and walk out the door with it.

We can do rate limiting etc on our own site, but third party vendors (think SalesForce and the like) have customer emails also.

I'm wondering what best practices large companies have developed for this.  I was thinking of doing an obfuscated email (sort of like craigslist) and using this for all employee screens and third party vendors.  This email would forward to the user through some special postfix server I setup, but could be turned off if the obfuscated one got out in the wild.

Then maybe only allow sending from certain addresses (or ip's) since an email blast could still go out to all obfuscated emails before we were able to turn it off?

This could require a large whitelist though, since we work with a handful of third party vendors that email customers on our behalf.

Any help or ideas appreciated! I imagine this has been solved before at larger companies. Thanks!

There is a great book about this and lots of similar problems from Peter Wayner, called Translucent Databases

About this question:

you can find customer by email if you store hashes of emails and compare them to the hash of the search query (exact matches only, sorry)
then, a salesperson could send an email via some kind of web app or a SMTP gateway which redirects hash@yourcompany.com to customer@domain.com, performs rate limiting AND logs who performed the request

This will do a good job against accidental errors, but for more detailed scheme you should more carefully model your "attackers" and business processes, and then apply practices from the aforementioned book (or similar ones)


Does the CVSS impact score correspond to probability? From  http://nvd.nist.gov/cvsseq2.htm, I noticed that the CVSS standard attributes the following impact values for confidentiality, integrity and availability:

  0 for none impact,
  0.275 for partial impact and
  0.66 for complete impact.

My question is the following:
what theses scores really represent? Is these values correspond to probability ?

No, they do not. They are impact scores.

The page you linked to in your previous question on this details it: http://nvd.nist.gov/cvsseq2.htm


Password Managers: encrypted database vs hashing strategy I'm considering moving to a password-management strategy based on supergenpass or something similar. This is an alternative to other password managers where instead of having a database of passwords encrypted on your master key, your password for any individual site is a hash of your master key + the site's domain name, e.g. if your secret key was "hunter2", your password for google would be sha-256("hunter2google.com"). As far as I can tell, the advantages over a traditional password manager are:

No encrypted database which has the potential to be found and decrypted
No risk of losing your database, as long as you know your master key and the algorithm you will always have access to all your passwords
No hassle with sharing your database across devices. This scheme is decentralised, and you can use it across multiple devices trivially.

And the disadvantage is that you're sharing a poorly-salted hash of your master key with every site you use this scheme to log into. But if your master key is sufficiently complex, reversing its hash is impossible, right?

Is there anything I've missed? Is there a more substantial security difference between these two password-management strategies?

As @CodesInChaos comments, an encrypted database, if done properly, will be at least as strong against brute-force attacks as a hash value. From that point of view, the hash-based method is not more secure. There are details, though, depending on the attack model:

With the local database of passwords, you can use random site-specific passwords. If one site is hostile, then it may learn your password for that site, but this will get him nowhere because there is no actual mathematical relationship between the master password (for database encryption) and the password you show to the sites. On the other hand, you have a local database which you must store somewhere (e.g. in your laptop computer), and if an attacker steals that storage then he can try an offline dictionary attack (i.e. brute force on your master password).
With the hash-based method, there is no database at all, hence the laptop theft scenario no longer threatens the confidentiality of your passwords. For that specific attack model, the hash-based method is superior. However, it also implies that each site-specific password can be used for an offline dictionary attack on the master password. So that's the trade-off: you are depriving the local thief from means to attack your master password, but you are giving such means to every site you register in.

If your master password is strong enough (say 80 bits of entropy or more; less might be sufficient is proper password hashing is used), then dictionary attacks don't work, and both methods have equivalent security (i.e. "not breakable through brute force").

If your master password is not strong enough, then I'll tend to prefer the database method, because ensuring physical security of a single laptop looks easier than ensuring that every single site I use is honest, competent, and not under hostile control.

As for usability, one may note that the hash-based method has the following issues:

You get only one password per target site. If the site wishes to force a password reset, and filters out attempts at reusing the same password, then you lose.
All sites don't have uniform requirements. In fact there is no password which could be used on every site, because length and contents requirements used in practice are not compatible. For instance, some sites mandate a minimum password size of 10 characters, while others mandate a maximum password size of 8 characters; there also are conflicting requirements on use of punctuation signs, digits,...

Both issues are easily solved by keeping track of site-specific password requirements, and possibly a site-specific counter or salt value to handle resets. But that means a "database", which voids the usability advantage of the hash-based method. That database contains only public data so it needs not be encrypted, but that's all.


How to add a malicious file scanner to live server? One of my WordPress websites recently got hacked, and I had to download the full website to my local PC and clean it.

As soon as I downloaded the website, my antivirus software found the malicious code and quarantined it.

Is there any way that we can do the same on the live server cPanel? like a malicious file scanner?

A little bit of googling(after on access scan clamav) came up with Clamuko, it seems to let you enable on access scanning of files.

The question that remains is if clamav would have caught the threat. Another option could be to look into Sophos' Linux scanner, it can also be configured for on-access scanning

Quick little sysadmin edit: I wouldn't suggest having on-access scanning on a busy site since on-access scanning will block the io operation. Regular full system scans where you email the result to yourself(and any other admins) and read them


How to stop quick access from saving encrypted folders? I use hidden veracrypt drive. It work by saving encrypted drive inside another encrypted drive, so that I can type one password to show fake data and another to show real data. But when I go file explorer, it show frequently used folders in "Quick Access".
I want to stop veracrypt folder from showing in Quick Access and make sure they are not in any file explorer history at all, how I do that? Will disabling "Quick Access" stop file explorer from saving my history?

I see "clear" option for history. Do I need to clear it every time I use veracrypt? Or should I not give real names to my folder?

Here is image of quick access (from sidebar of file explorer) "Secret folder" is my folder that is appearing that I don't want to appear.

I found the documentation for this Issue and it basically says, to be save you have to use a hidden Operating system when mounting your volume.

https://veracrypt.codeplex.com/wikipage?title=Security%20Requirements%20for%20Hidden%20Volumes


Assuming I own the client. Is it acceptable to embed my authorization servers login page in an iframe? We have an authorization server which exposes a login page, we would like to authenticate users in our single page app using this authorization server. My employer does not want to redirect users to the authorization server to login due to UX, and I do not want to resort to using the resource owner password flow.

Since we are developing the client ourselves is it acceptable to embed the authorization servers login page in our client via an iframe, prevent other websites from embedding it via the Content-Security-Policy header, and use the Authorization code flow + PKCE?

If it helps we are using IdenityServer4.

EDIT:
From what I understand the main concern with allowing your authorization servers login page to be embedded in an Iframe is that it would be susceptible to click jacking attacks. But if I add headers which only allow it to be embedded only in trusted clients we would be protected against that, assuming the end user is using a compliant browser. https://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-10.13

You simply develop the client, you don't own it. As soon as someone installs it on their devices, you don't own it anymore.

Anybody can then analyze the client code, find the authorization server, and access the URL from outside, by hand. Content Security Policy is an agreement between browsers, so if I run the request by hand using curl, for example, CSP will not save you.

Ask your employer why the redirect is not allowed and what he suggests. Embedding the authorization server in the client is asking for someone to decompile it, find the authorization process, and create a "keygen" in a couple hours.


Do I need to keep certificate signing requests and public keys? I've created an RSA key. Created a CSR. Got it signed and now I have my certificate. It's for a webserver running https.

The public key can be generated from the private key, so I guess I don't need to keep a separate file with the public key in unless my application needs it (it doesn't).

But can I just delete the CSR now or does it contain anything I might later need?

There's no need to keep either. Of course, you may want to store your public key for convenience (should you ever need to use it directly). For example, I keep my SSH public keys even though I can regenerate them whenever I want -- If I need to copy a specific key to a server, it's more convenient to not have to generate it.

The CSR is also something you can regenerate given the private key. The CSR itself has no power after the certificate is signed. It's OK to release it publicly or to delete it.


Bypassing HDD Passwords I dismantled a broken old laptop for spare parts. I'm trying to salvage the old Seagate mechanical HDD but it (firmware?) is password protected. I'm not sure if that means it's encrypted or not.

What are my options? Can I bypass or defeat it somehow? Failing that, can it be erased, formatted, or overwritten with a fresh OS?

Here are some screenshots to illustrate what I'm dealing with:

Traditionally an ATA disk password will not enable encryption for data at rest on the disk. BIOS factory reset will not reset what is known as the ATA User password. The ATA Master and User passwords are stored on the disk drive's physical firmware.

The drive can be unlocked using a (factory-installed) Master password (which generally only becomes relevant when the User password is set) or using the User password.

For some fun background reading on the the use of ATA passwords and disk drives refer to the T13 Working Group ATA Command Set (search the PDF for password).

There are several tools and techniques available to obtain the Master password depending on drive type.

I have not had to workaround a Seagate drive, but the general order involves feeding a manufacturer specific script (available on forums) to a tool like MHDD or Victoria to dump data located in the drive's firmware which contains the Master or User password, parse and translate (with your brain) the output with a hex editor to yield the Master or User password, and then use MHDD or Victoria to unlock the drive with the password.

There are many posts on hddguru forums outlining the process for various manufacturers and drives.


TCP Hijacking and conflicting data handling on the OS level Assuming I perform a TCP hijacking attack, by having access to the wire on which packets are being transmitted. In practice, the party to which I'm sending the hijack packet is going to receive the data of the specific sequence number twice - once from my hijack packet and another from the other party.

What does the TCP specification say would be the right way to handle the conflicting data? Is the Operating System supposed to take the first copy of the data, the last copy, or is it unspecified? If unspecified, what's the common implementation in practice for most Operating Systems?

I know that when loosing the race to inject my packet into the session, my data arrives second but it's ignored by the application. However, this doesn't give me any indication on whether this is because the application already read the data from the buffer of the operating system, or whether it's just ignored by the operating system and so it doesn't matter when does the application read the data.

Currently, if I'm trying to hijack a non-secure HTTP session and redirect it to a different site, I send an HTTP redirection and make sure to close the connection - to avoid relying on this sort of implementation detail on the side of the TCP stack. However, I wonder if this is really needed.

The premise of TCP is that it handles connectivity-layer things and limits the application's exposure to a reliable data stream.  Therefore, these things are taken care of at the OS level for TCP (but not, say, UDP).

The TCP stack should discard duplicate packets and data (e.g., overlapping packets) before the application sees them.  TCP relies upon sequence numbers to determine if data is duplicated, in part or in whole, and will discard any duplicated data.  To quote RFC 793:

  At the receiver, the sequence
      numbers are used to correctly order segments that may be received
      out of order and to eliminate duplicates.

and

  Initial tests on arrival
          are used to discard old duplicates, but further processing is
          done in SEG.SEQ order.  If a segment's contents straddle the
          boundary between old and new, only the new parts should be
          processed.


How to sign data with OpenSSL 0.9.8? I am building a license generator for nodejs and I am currently testing on Heroku.

On my local machine running OpenSSL 1.0.1g, I'm able to test my key pairs (sign and verify) like this:

# data.txt's content (the content of the string literal): "Tsenkov"
openssl dgst -sha1 -sign private.pem data.txt > license.txt
openssl dgst -verify public.pem -signature license.txt data.txt

But on Heroku (OpenSSL 0.9.8) I get the following error:

Error Signing Data
27:error:0606B06E:digital envelope routines:EVP_SignFinal:wrong public key type:p_sign.c:99:

Here's how my pair is generated:

openssl ecparam -genkey -name secp521r1 -noout -out private.pem
openssl ec -in private.pem -pubout -outform PEM -out public.pem

I remember having the same problem on OS X 10.9.2 (local machine), but before trying anything else, I updated OpenSSL through Homebrew and it miraculously started working.

I guess there's an older way of signing data (syntax, etc.) which I'm not aware of.

Can someone help? Thanks.

OpenSSL-0.9.8 is old (from 2005) and support for elliptic curves was not completely added at that point, especially for the command-line tools. OpenSSL is primarily a library; the command-line tools are provided for testing, but are often lagging in functionality. The "normal" way to use OpenSSL is programmatically, by writing C code which calls the library.

MacOS X still uses OpenSSL-0.9.8 because the OpenSSL people broke binary compatibility for some functions, preventing MacOS from doing a transparent upgrade (it could break some applications). Apple's reaction was to mark all the OpenSSL functions as "deprecated" (you get a ton of warnings if you compile C code using the system-provided OpenSSL headers) and write their own cryptographic library.

In any case, you should want to upgrade, not only for better functionality, but also for security (for instance, some algorithm implementations got some extra shielding with regards to side channel attacks) and for performance (e.g. on a 64-bit x86, RSA will be 5 or 6 times faster with 1.0.1g than with 0.9.8).


Am I missing something in regards to using third-party PHP libraries? I "minimally trust" the PHP and PostgreSQL projects to provide non-compromised binaries of their respective programs, which I both depend on. This means that I trust them in the sense that I have no real choice but to trust them.

However, I have well over 100,000 lines of third-party PHP libraries (managed through Composer) which I also am forced to blindly trust in practice. Even if "Symphony" might be a large project, and perhaps not too likely to contain malicious injected code, there are various obscure PHP libs created by a single guy 5 years ago, who I'm forced to trust an equal amount. I do not trust those whatsoever, but I have no choice but trust that they don't log in to their Github account and make a change which steals all my data and have me auto-fetch it with the next time Composer runs its update mechanism.

(I don't even use Symphony myself. It's a massive dependency by some other third-party PHP library.)

Why is there no "protection layer" for this? I'd like to be able to tell PHP or Composer that "this library does not get to use the network connection whatsoever, and can only see this directory, and cannot launch any commands on its own", etc. You know, some kind of minimal protection layer to avoid a catastrophe when ObscureAuthor's little PHP library gets "hacked" on GitHub and starts sending my wallet.dats to some server in Russia.

At least with a security layer as I describe, the worst thing that could happen is that the library starts lying about numbers to my own application's scripts, but at least it cannot do fishy things freely over the network and stuff like that which I fear constantly.

PS: Please do not tell me "Docker". Docker is vaporware to me. I've tried to use it for literally many years but still haven't figured out how it's supposed to run, so no, it's not easy to use and not what I'm talking about.
PS 2: I can't follow the advice to "use only major libraries" because extremely few libraries are anything but obscure and have a monopoly, meaning there are no alternatives.

Disclaimer: I am not a php expert, but this seems to be a question that pertains to package management in general.

Every package manager suffers from this, whether it is npm, composer, gem, etc.

npm (Node Package Manager) suffered from exactly this scenario a couple years back.

What some package managers do to mitigate this, is require repositories provide a cryptographic signature with the package being installed, so that if the package was tampered with and not signed by the owner, it will be flagged by the package manager.

Some package managers also do vulnerability scanning, for reported vulnerabilities in the version you are dependent on, so you know to upgrade.

Using third party software requires trust (on the developers, on the repository where it is imported from, on the software it depends on) for more than just security, and there are no silver bullets.

If your package manager does not do the minimum of package signing, then switch to one that does if possible or put pressure on them to do so.

If you have the backing to do so (I am not sure if this is a personal project or a work project), you (or your company) could set up your own repository that only contains packages you (or your company) has audited and configure your package manager to point to it. This keeps risk at a minimum, but requires quite a bit of effort.


Is forcing users to change passwords useful? In many places, there's a policy that force the user changing it's password once a few months. The logic here is, that even if the password have leaked somehow, it'll be abused only for a relatively short period of time. So that a note with your password you threw to your bin now, will not come and hunt you in five years.

But what this policy is missing IMHO is, the people factor. What many people usually do when forced to change their password, is to choose a new password not to too far from the original one. Since it's hard to memorize the new password every month. For example

foo1bar
foo2bar
foo3bar

or so. So an attacker with a minimal amount of sense, would activate john-the-ripper or equivalent, and find out your password in no time. Heck, the entropy of the new password given the old password is typically so low, so that you can even bypass a password system that alerts the admin if you entered the wrong password three times in a row. You'll probably find the new one within 10 trials, and given that the user logs in once a day an attack will be able to find it out within a month.

So I'm asking, will a policy that force users to change their password once in a while actually provides more security than its cost?

As you note, when you force users to do something, they do not like it, because it makes things more difficult for them. Users rarely focus on security; it is not their job, and, instead, their job implies going through the hoops that the security department comes up with. So they react logically, by taking measures which make their life easier.

Classical countermeasures employed by users include:

simple derivation of the new password from the previous one (but there are password management interfaces which try to prevent that: "the new password is too similar to the old password");
cycling through a list of passwords, usually reduced to two passwords; the user just swaps his "normal" and "alternate" passwords whenever a password change is requested (to prevent that, the password management system must remember previous passwords, which can itself be a security hazard);
the all-time favorite of writing the passwords down on a sticky note (cunningly hidden under the keyboard);
getting passwords from a "natural list", e.g. current players in a soccer team (it is not easy to make an automated test which will detect that, but a human attacker with half a neuron will handle that easily).

So the increase of security through regular password change will be, at best, dubious. Its main virtue is to avoid the establishment of a local "traditional password" which employees communicate to each other for years, and previous employees keep on remembering.

Theoretically, regular password change might give users a sense of "something worth protecting is going on" and prompt them into being more cautious with their passwords; in practice, I have never witnessed that.


Verifying Encryption at Rest with Oracle 11g I have a big giant database that is basically human resources related. As such, it contains all the PII in the world (SSN, medical related stuff, bank payment info, etc).

If you do not request PII access permissions on the database, PII fields return NULL. If you do receive PII access, everything is displayed in plain text.

As a user and not a database admin, how do I guarantee that the PII itself is secured at rest? I presume that when I log in with my PII viewing privileges, some transformation is done on the underlying data to make it human readable. How do I make sure that when its physically sitting on disk its NOT human readable?

Oracle has this description here and an example of using a java class to decrypt PII but it is murky about providing me a way to verify that decryption of the underlying values is happening under the hood before I see plaintext.

If you can look at the database, you can look at the actual tables and see that the data is stored in an encrypted format, or if its' stored in plaintext. You can also check that the entire database is/is not stored as an encrypted object.

If you have access to the source code for the software serving the database info you can check the logic in the function and see if it encrypts/decrypts data as it is entered into the database or removed.

If you have access to the server as a whole you can check that disk encryption is in use.

If you have access to nothing your easiest way to check is to see if the software used is listed as being compliant with HIPAA/PCI regulations, and see what their website or your systems' administrator can confirm to you.

At the end of the day without knowing what software serves you the SQL tables, and without having access to view the SQL tables, it's kind of an open-ended question that is probably best resolved socially rather than technologically - ask someone who knows.


Cookie Tossing explained Can someone explain to me what cookie tossing is? and how it can be used to hijack someone's session? and also how can we prevent it? I am a bit confused about this subject.

Cookie tossing is an attack which abuses the feature that a subdomain can put a key=value pair in a cookies which can then also be read by the domain above it. For example, when security.stackexchange.com sets a cookie, stackexchange.com will be able to read it. Unfortunately there is no way for stackexchange.com to see if the key=value pair comes from stackexchange.com or from security.stackexchange.com. So when stackexchange.com uses the same key for some of its own functionality, it might mistake the value from the subdomain for its own value and treat it as if it set it itself.

This becomes problematic when a website allows untrusted people to host subdomains under its domain. They can then abuse this feature to write manipulated cookie information. The ability to take over a session this way is limited, because the attacker can only write information, not read anything. However, setting arbitrary cookie values can in some cases be used for a CSRF attack or an XSS injection, depending on what the main domain does with the content of the cookie.

Protecting your website from this is easy: When you use cookies for anything on your main domain, don't let anyone you don't trust put their content on your subdomains.


Can my ISP read my gmail even when using HTTPS? Is there a way to prevent that? Can my ISP read my gmail or other email even when using HTTPS?

I guess they can do that since they are the "man-in-the-middle".

Is there a way to prevent that?

This is related to the news that in my country (Uruguay) the government ordered the ISPs to add a software that can read all emails.  (http://www.elobservador.com.uy/noticia/289757/el-guardian-espiara-desde-enero-mails-y-celulares/)

No, they can only see the encrypted traffic flowing from yourself to Google's servers.  They cannot see the actual content of the traffic (your emails).

However, if your ISP forces you through a web proxy and makes you use their certificate, they could then see the content of your traffic.  I would be cautious if you see untrusted certs when going to gmail.com.  You may consider even using a VPN to prevent your ISP from trying to do things like this.


ssh login failure detection at packet level There was one person I met in blackhat mentioned that SSH login failure can be seen at packet level because the SSH protocol will indicate whether login is a success or failure.

I think the login process is considered as normal data by ssh protocol and hence it's transparent to ssh protocol itself. There is no indication in the packets whether ssh login is successful or not.

Can anyone confirm this?

Thanks.

Before the password is sent, an encryption layer is added to the connection.

Also the encryption fingerprint is compared to the last time you signed in successfully. If there is an MITM inserting its own encryption layer then you will be alerted of the changed fingerprint. (assuming you have not already accepted the incorrect fingerprint by accident)

While the password, and the response from the server cannot be seen directly, it is likely that you can tell by the packet size and timing, and how long until the connection was closed, whether the login attempt was successful.

For example, this would be a single chunk of data with a predictable size.

Invalid username/password, please try again.

On the other hand, a successful login is several lines

Welcome! It's a great day at XYZ server!
Your last login was yesterday at

And depending on your server, there may be a delay between lines, which is sent in separate TCP packets as it comes in.

You have new mail.

you@xyz:~$

So yes, you can tell by monitoring packet size/count/timing whether the sign-in was successful. You cannot tell what password was attempted or exactly wad data was transferred.


Recommendations for honeypot software A couple of us wanted to setup a honeypot/honeynet with the goal of learning; not planned to be in a production environment. What's a good recommendation for a high interaction or low interaction honeypot. Also we'd like to eventually report the findings into some kind of businessy style report so something that compiles the information would be good too.

I've looked into the following but if you like these please let me know why:

honeyd - great overall but a low interaction honeypot
mwcollect/nepenthes - most well supported but too low of interaction
cuckoo - sounds interesting but difficult setup and outdated documentation

EDIT: Which honeypots have given you the best results for malware analysis. Low interaction honeypots will not go much further than pretending to have a port open, but I'd like to track an attack, allow the payload infection, contain it from anywhere else, and generate a report based on that and then after the attack, start over again with a clean environment.

Does anyone do honeypots anymore? :)

I don't have the exact specs to hand, however we used to run a very successful wireless honeynet based on freely available sources which we would take to sensitive environments to see whether there were active attackers in the environment, and what they would do.

Core to our setup was a laptop running a honeynet based environment, with simulated traffic between multiple virtual hosts running in VMs to look like finance servers, databases, users etc. Without that emulation of real world traffic an experienced attacker will realise very quickly that they are within a honeynet.

On another laptop, connected by a uni-directional ethernet cable to prevent its visibility to the attacker , was our logging platform. Again, if an attacker spots a logger which is not appropriate for the supposed environment, they will be suspicious.

This honeynet was quite configurable, and although it did take a fair amount of work to set up initially (one of my team created most of it) he said it was pretty straightforward.


White hat "ethical" hacking legality I was preparing a presentation on White hat hackers and ethical hacking, I organized it this way at the moment:

This mindmap is a draft version, of the final thing. By defense, I meant security manager, the ones using black hat techniques to mitigate security flaw, and by attack, I meant NSA and those kinds of organisations.

What I found very interesting is the aspect of legality behind all this, and it's not so easy to find. I found out security manager use nearly the same techniques as black hat but somehow it's legal. Same goes for NSA ones, but I'm having a hard time but this second one. I mean let's say it's USA vs Russia, hackers working for USA government sure will be white hat for USA, but how are they going to consider hackers from Russia's government since they are "enemies"?

You appear to be thinking that actions have universal goodness or badness. This is not true.

A white hat hacker, or a security manager, has permission to do what they do. That is the biggest and most fundamental difference. Without permission, it is no longer "white" and it is no longer legal, in many jurisdictions.

NSA hackers have permission from the US laws to do what they do, but they do not have permission from Russia to do what they do. This means that they are not white hat hackers. They are attackers. It's the same for any country.


Password on login idea In addition to the standard best practices on password logins. Has anyone considered a captcha like system but instead of just typing out what is in the captcha, the captcha will be directions on what you must do to your password during the login.

For example if my password was "password123" on the login page if I used that password it would not work. If you follow the message it might say something like add the letter "E" after the second letter in your password then add a "!" symbol at the very end. So a successful loging would require "paEssword123!". The requirements and complexity of the password alterations could vary greatly from one change to multiple changes to the types of changes. Every attempt would generate a new random set of password alteration requirements. So if they typed it in wong the next login might say capitalize the first 3 letters and lowercase the rest of the password, then add the number 5 in the second to last character spot (PASsword1253).

EDIT: You could not do capital/lowercase changes because since the original password is unknown the system could not strip out the alterations it asked for before testing the real password. But you could still do additions of characters.

Therefore (other then when they first created the password) their password is never entered into the website again as the exact password. So keyloggers wouldn't be able to just copy what they type in because the password would technically be different on every login attempt.

Granted if there was keylogging they might have 90% of the real password (depending on how much a user had to modify it during logins) but it still would make it much harder to guess and then write software that could read the rules of the captcha and alter the password (and they wouldn't even know what the real password is at this point) each time in a brute force attack.

Browser password saving or anything that saves passwords for you would not work, it would be little bit of a pain each time you had to login but if this was important data like bank information I would be willing to spend a few more seconds logging in for extra security, esp. against things like keyloggers.

Other then users having problems following the rules during the login, are there any other flaws to this idea? Does it sound like it would work or not work and why?

Thanks for your opinion.

Interesting idea, but there are a number of reasons why this does not add as much security as you hope.

First, software based keyloggers typically have luxury of being able to not only receive what you type, but also see what you see. In particular, if a bank introduced such a system then a short while later malware would appear that logged what you typed and what the modification instructions were. This is an on-going arms race situation with banks and malware developers right now, which is why we have "please enter select the 2nd, 3rd and 7th character of your password".

Second, you'd also have to significantly increase the allowable number/frequency of incorrect password entries, making brute forcing easier.

Third, users typing in their password with this scheme would be much easier to shoulder-surf, as they would be typing their password much more slowly.

(The question already captures the fact that a keylogger would already have the majority of the password - any guesses what this user's unmodified password was? "PassQword1" ?)

I think you already capture the main downside - usability:

It wouldn't work with many password saving devices, encouraging you to use a simple password you could easily remember (and hence could easily guess).
It would frustrate and hence drive away users (unless it was ubiquitous - but early adopters would have to overcome this barrier).

Given the limited security benefit and significant usability impact, this scheme would probably not be widely adopted (which, of course, would increase the security benefits to anyone who did adopt it - there would be unlikely to be any malware designed to read the instructions; nor tools to reverse the modifications).