Is there any security concern if I kept password hash on client side? I have a mobile application that needs to be able to work when the phone is offline. In order to prevent misuse by others when they have a short physical access to the phone the requirement is to authenticate the user every time the application gets opened, i.e. even when offline.

By keeping a hash of the password on the phone I would be able to authenticate the user even when offline. Are there any problems with this approach?

Well, first and foremost, check you are hashing and salting the password correctly. It is a lot more critical if the hash is available more easily to attackers. Also keep in mind that even correct hashing can't protect short passwords from determined attackers.

Second of all, if you are using this hash to the authenticate to the online server, you should be aware, that if someone gains access to this hash, they can authenticate to your server. Because the client app can authenticate just using the hash, the attacker can also authenticate using just the hash. You may want to add some nonce to this, that would change on every online login, in order to prevent reuse after a client logs out.

Finally, be aware that you should hash the hash on server side once more (normal SHA2 will suffice), otherwise if someone obtains the hash from your server database, they would be able to authenticate as well. If they obtain a hash of the hash, they can't get the hash that can be used to authenticate.


Can one trust OS and apps from Onyx: app store, modified Android, Onyx Cloud Onyx Boox is a brand of e-book reader produced by Onyx International Inc, based in China. They have e-book readers based on Android OS. They have features that can violate user privacy or other accounts security:

App store with optimized for e-book apps from other App stores: kindle, office, evernote and etc
Account manager: Dropbox, Evernote and etc
Option to enable Google play and other Google services (like Calendar)
Onyx Cloud (sync personal notes and etc)

So the question is: are there any sings of backdoors or vulnerabilities known about their modified apps or OS itself or other stuff that can lead to user data leaks (like privacy leaks or leaks of sensitive information: like passwords or other data)?

I think this is a personal question, and I doubt anyone can give you a definitive answer. Only you can decide whether you trust a company which offers a certain service, and this in turn depends on the service itself and on your personal threat model.
Are there opportunities here for something nasty to happen to your information? Certainly, but that can be said for every product out there. The real question is: are these risks that you are willing to take in order to use this product? This is the real question.
Also, the question in its current form is probably too wide: all 4 points you raised would require an in-depth security discussion, as the attack surface varies wildly between them. Your attitude to risk could also easily be different depending on the point you raised: for example, you might trust their cloud enough to store your documents there, but you might not want to give them access to other clouds such as Dropbox or Evernote. Once again, this is not something that we can answer for you.
If you are interested in a thorough review, your best best is to reach out to the producer and request some security documentation, so you can make an informed security decision.


What is the significance of the version field in a TLS 1.1+ ClientHello message? I am trying to add TLS 1.1 and 1.2 support to a packet capture product which already has TLS 1.0 support.

I have used Wireshark to capture traffic between my browser and an openssl server to generate some test cases. I have seen an unexpected TLS version flowing in all the traces I have created.

Secure Sockets Layer
    TLSv1.2 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 105
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 101
            Version: TLS 1.2 (0x0303)

The above is an extract from one of the TLS 1.2 traces as reported by Wireshark. The version given is TLS 1.0 in the ClientHello and 1.2 in all subsequent messages. This happened in both the TLS 1.1 and 1.2 traces.

Appendix E.1. (Compatibility with TLS 1.0/1.1 and SSL 3.0) from the TLS 1.2 RFC says:

Earlier versions of the TLS specification were not fully clear on
what the record layer version number (TLSPlaintext.version) should
contain when sending ClientHello (i.e., before it is known which
version of the protocol will be employed).  Thus, TLS servers
compliant with this specification MUST accept any value {03,XX} as
the record layer version number for ClientHello.

That in itself is also a little ambiguous to me.

So my questions are:

Can this field be a completely arbitrary value (as long as it is SSLv3 or higher)?
Will the behaviour change depending on the version given in this field?
Is there some significance to the browser choosing TLS 1.0 rather than SSLv3?

Related:

https://security.stackexchange.com/a/26059/7866 This answer suggests that SSLv3 should be used in the ClientHello for maximum interoperability. The mention of interoperability implies that the server cares about what value is given.

Version fields occur in three places:

as part of the header for each record that the client and the server send;
as part of the ClientHello message from the client;
as part of the ServerHello message from the server.

Protocol Version Negotiation

The version field in the ClientHello is the maximum version supported by the client implementation. For instance, when the client puts 0x0302 in this field (that's the conventional value meaning "TLS 1.1"), the client tells the server: "I am ready to handle all protocol versions up to TLS 1.1". The version field in the ServerHello message from the server specifies which protocol version will be used for this connection. The server should use the highest protocol version that both client and server support.

The client should not announce support for a protocol version that it does not actually support, lest a server would choose such a version, mistakenly believing that the client indeed supports it.

About Records

The ClientHello from the client is sent wrapped into one or several records, and each record contains the protocol version as well. The records are like the envelopes around letters. It is safe to use version 0x0300 (SSLv3) for these records, regardless of the maximum supported version indicated in the ClientHello; that's like sending a letter in an SSLv3 envelope, but the letter says "by the way, I also support TLS 1.0 and TLS 1.1". Using SSLv3 records maximizes interoperability with old and buggy implementations who know only of SSLv3 and would reject records with a higher version.

The response from the server states the protocol version which will be used, and should come as records bearing that version. E.g. if the server says "TLS 1.1" in its ServerHello then that ServerHello should come wrapped into a record also tagged as "TLS 1.1"; and all subsequent records from both client and server should use that version.

Interoperability

Theoretically, a server should accept any value greater than or equal to 0x0300 in a version field, and should not complain if it contains, e.g. 0xA7C0 (meaning "TLS 165.193", a fictitious version which will probably never be defined). This holds for both the ClientHello message, and the record headers. The protocol version impacts the encoding of records, but the first records are in cleartext (no cryptography), and for them the version can be ignored because cleartext is cleartext (SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2 cleartext records differ only by the version specified in the header, but are otherwise identical).

In practice, there are reports of widely deployed implementations which do not tolerate "version" fields where the first byte is not 0x03. There even are implementations which do not support a ClientHello which specifies a version higher than 0x0301 (aka TLS 1.0).

To minimize issues, a client:

shall use SSL 3.0 in the records for the ClientHello;
should specify its highest supported version in the ClientHello;
may fallback, on failure, to trying the ClientHello again, this time claiming a lower maximum supported version (to accomodate old servers which get a stroke when they see "TLS 1.1" or "TLS 1.2").


Are there solutions to managing AWS root keys by a team? Within our corporation, we have a dedicated team that manages our AWS footprint. For each dev/app team, we provision a new account with a VPC and some networking to attach it to our pan-galactic network mesh.  However the root keys for that account owner are kept and managed by our AWS management team.  The devs are allocated IAM accounts with superadmin privs so they can pretty much do whatever they want but we still maintain master control.

The problem is that with a team of people, you can't easily create the root account and attach MFA to it.  Amazon has some suggestions that basically boil down to setting a complex lengthy password on the account then just lose the password.

Are there solutions that enable a group of individuals in a team to manage a common MFA so we can enable MFA on the root account?

In a properly secured AWS account, the root account should only be used as a "break glass in case of emergencies" thing. Users should be using IAM accounts as their "daily driver". I would enable MFA on the root account, and print or save a copy of the QR code. Put it in a safe or vault. Only pull it out when you need it.

You can scan the MFA QR code multiple times, so you can have several devices setup for MFA.


How can I use netcat like ping? How can we use the netcat (nc) to determine whether a particular machine is running web, mail or SSH services?

To identify if a server is running, you only need to determine if the port is open for requests.  Using netcat, you can query a server like this:

nc -z www.example.com 80

This will tell you if it's listening on port 80, the web port, but it won't tell you anything else about the server.

To use netcat to learn more, you need to pass it the correct data to elicit a valid response.  That means you have to understand http if you want to find out if it's running a web server, smtp if it's running a mail sender, etc.  You have to know what port a web server runs on, the name of the server, the protocol, everything.

Here's a simple example of how I'd determine if www.example.com was hosting a live web server using netcat.

echo -e "GET http://www.example.com HTTP/1.0\n\n" | nc www.example.com 80 | less

If this comes back with a response containing HTTP/1.0 200 OK, it's running a web server on port 80.  If not, it may not be running a typical web server.

You'll have to discover and understand the protocols of mail servers and ssh servers if you want to query them in a similar fashion.

Netcat is really the wrong tool for this job, however.  If you want to identify the kinds of servers a host is running, nmap is a much better tool as it's kept current with the various fingerprints of common servers you're likely to encounter.


Using TLSv1.2 on Weblogic server for outgoing transactions with IBM JDK I am trying to use TLSv1.2 for all communications going out from my Weblogic application server(acting as SSL client) but couldn't use it.

System details:
Weblogic 12c
IBM JRE7 SR9

Things I have tried:

Enable only TLSv1.2 on weblogic server by setting the property weblogic.security.SSL.minimumProtocolVersion=TLSv1.2, but it didn't work. I have confirmed that by checking the SSL logs on weblogic server. Weblogic starts the SSL handshake with TLSv1 instead of TLSv1.2 in ClientHello message.

By default the TLSv1.1 and TLSv1.2 are disabled on JVM started as client so I started the weblogic server as server by turning on the production mode in weblogic scripts but again didn't work.
I also used -Dhttps.protocols=TLSv1.2 but same result. Weblogic starts SSL with TLSv1 clientHello message.
I tried Weblogic server with Oracle java, everything worked fine by setting the minimum protocol version only.
I enabled the useSunHttpHandler property on weblogic by setting useSunHttpHandler=true and used https.protocols=TLSv1.2, it worked with IBM java as well.
I enabled same property useSunHttpHandler=true and used weblogic minimum protocol version as TLSv1.2(didn't set the https protocols version though) and it didn't work.

Really confused why it's not working.

Please try disabling Lower protocol in java.security file.

Property Name jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1

Your minimum java version should be 1.7 to use this property.


Luks+Sleep: Login screen security? Situation: A Desktop Linux (eg. Debian, Xfce desktop, Lightdm login) with LUKS-encrypted partitions (as far as possible, eg. Efi files are not encrypted of course).
The computer is in sleep mode (not hibernate, ie. Luks in unlocked and key in RAM).

Now a thief steals the computer and wants to find a way in.

Anything that involves turning it off will of course not help because of the disk encryption.
Installing hardware keyloggers, replacing Bootloader/Efi with something maliciours, and similar things won't help because the owner knows it is stolen and it can't be trusted.
Elaborate attacks that eg. read the keys directly from RAM through some means are outside of the thiefs capabilities and/or a risk that the owner takes for being able to use sleep instead of shutdown.
That leaves the risk that the login screen (of LightDM) can be bypassed somehow, given the already running Desktop behind it.

My question is, what things I do need to be aware to prevent this?

Following points I already know:

Switching terminals (CtrlAltFn).

It the GUI is started with startx, this allows to get an TTY where the user is logged in already. However there is no such TTY when using LightDM.
There is also a GUI screen which just displays "This session is locked, will switch to login in few seconds" (or similar message). However it doesn't appear that there is an easy way to break out from that.

X Server has a DontZap config option which allows to kill X with the shortcut CtrlAltBackspace. This might help in the "locked" screen or even Lightm, however it is disabled by default, so no problem.
There is another X shortcut CtrlAlt* (star) (config AllowClosedownGrabs) which kills all processess that hold a "lock" (whatever lock this means). This too is disabled by default.
Kernel SysRQ shortcut F for OOM killer. Can be disabled, and maybe the two GUIs are among the processes protected against it (I tried about 50 times and and failed to kill LightDM, just not sure about the exact reason).

What other risks might be there in 2018?

Assuming all relevant SysRq features are disabled when the lock screen is active (SAK, sending SIGTERM or SIGKILL to all processes, triggering the OOM killer as you mentioned, etc), and assuming advanced attack vectors like DMA attacks, cold boot attacks, and network exploitation are out-of-scope, then there is no way to bypass the lockscreen short of exploiting a bug in the code that is currently unknown (they are not too uncommon, though). In short:

Bypass may be possible by using other SysRq features you have not mentioned.
Bypass may be possible by exploiting an unknown bug in the lock software.
Infoleaks may be possible by plugging in a large monitor, triggering a resize.*
A local process could (intentionally or unintentionally) interfere with locking.

There are other, more secure lock programs out there. An example is vlock which works by opening a new TTY that it controls and disabling TTY switching. It also disables SysRq while it is active. It should be noted though that, if it is run from a terminal, it will exit if the terminal crashes for any reason (this is a bug which is easy to fix). The reason vlock is particularly secure is because it does not rely on the security of your X server, which itself has fundamentally no concept of lock screens. Instead, it is designed to utilize TTY isolation which is something that was designed with security in mind. Another alternative might be xsecurelock, a simple graphical lock screen created by Google which emphasizes security against crashes. However, like most screen lock software, it does not disable any SysRq features by itself, so you must do that yourself if it is enabled.

* If a large monitor is plugged into the locked computer, the root window may automatically resize itself. If the lock screen does not detect this and maximize itself again, it may be possible to see beyond the lock. This is not an issue with virtual terminal-based lock software like vlock, since the X server is in another TTY.


When self signing a key in `gpa`, what is the purpose of the "sign only locally" option, and what does it do? What does this "sign only locally" check box do or mean in gpa (the GNU Privacy Assistant)?

I'm working on verifying the fingerprints of acquired public keys, and once verified with their owner, then self signing these keys to signify that I've checked their authenticity.

It means if you export the key (e.g. with gpg --export ...) that this signature will not be exported with the key into the export output file.

Comparing the similar utilities gpa with kgpg (where KGpg is KDE's key management utility) you can see the similar, but more enlightening check box:


Where is the first online reference to the "HeartBleed" bug? From what I know, the HeartBleed bug seems to occur around 15 hours ago. As per heartbleed.com, the HeartBleed bug was independently discovered by a team of security engineers at Codenomicon.

How did the public came to know about the news?

Where is the first online reference to the "HeartBleed" bug?

Hackernews user eastdakota (probably Matthew Prince) is the CEO and co-founder of CloudFlare (according to the HN bio) and has publicly stated that:

  One of the individuals who discovered the [Heartbleed] bug contacted
  us as a large provider of SSL termination services. We were asked not
  to further disclose the details until it was officially patched and
  announced by OpenSSL. The official announcement occurred today after
  which we put up a post to let our customers know that they were
  protected.

And:

  ...we held the post informing our customers that they were protected
  from the bug until after it was officially announced by the
  organizations that had discovered it as well as by OpenSSL

And also:

  The bug was discovered by a researcher at Google and three engineers
  at Codenomicon.

Credits:

  The vulnerability was first reported to OpenSSL by Neel Mehta from
  Google Security. Matti Kamunen, Antti Karjalainen and Riku Hietamäki
  from Codenomicon Oy reported the vulnerability to NCSC-FI, who
  reported it in turn to OpenSSL. NCSC-FI would like to thank
  Codenomicon for reporting and analysing the vulnerability.

The heartbleed.com site is registered to Codenomicon

  Domain Name: HEARTBLEED.COM
  Registrar URL: http://www.godaddy.com
  Registrant Name: Marko Laakso
  Registrant Organization: Codenomicon Oy

So going from what Matthew has said, it appears that the first public disclosure was either the OpenSSL Security Advisory or heartbleed.com, and the rest is history.

The Cloudflare blog post is 21 hours old at the present time, with the Hackernews post now at 20 hours old, so the initial announcements from OpenSSL / heartbleed.com are probably not much older than that.

Edit: heartbleed.com now states:

OpenSSL Security Advisory (published 7th of April 2014, ~17:30 UTC)
Cloudflare Blog Entry (published 7th of April 2014, ~18:00 UTC)
heartbleed.com (published 7th of April 2014, ~19:00 UTC)


Which RFCs should I read for web pentesting? I'm new in web pentesting and I have read a lot of books.

But I think I should read some RFC to have a better knowledge about web applications.

There is a lot of RFC and I'm a bit lost on which one should I read...

i'm starting with RFC3986 but which ones would you recommend me after this one, please ?

Pentesting isn't about knowing RFCs by heart. If there is a specific information you need for a specific test, you can always just look it up.

It's much better to have broad fundamental knowledge, and know where to find specifics, rather than to attempt to cram as much specific knowledge into your head as you can.

The question "Which books should I read when starting Pentesting?" is very opinion-based, and will not be answered, as those answers would be outdated very quickly. One resource that comes up often is the OWASP Top 10, as those are vulnerabilities that come up very often, and understanding those will help you quite a bit.

Don't be afraid of asking well-formulated questions regarding your understanding of specific topic, even if they are not attached to a real-world problem.


Anonymisation better than just a hash I'm trying to help anonymise users but still give them some controls. So this is different from say, anonymising a data set where you never need to go back to the original users.

Let me give you an example. I want a user to come in with his or her email address to log into my system, but I don't want to store the email address. I want to assign that user a UUID that I will then use. However, if the user loses the random identifier they need to be able to re-enter their email address and then get back into the system.

The simplest answer to this is a hash. Of course I could store the hash next to the UUID. If they lose the UUID they can come back and I can re-hash the password. On the other hand, if my system is broken into, the bad guys can simply do a dictionary attack on a list of email addresses and then re-identify the UUIDs.

Firstly, is there a standard way of doing this? bcrypt and PBKDF2 pop to mind, but I obviously can't store a tuple of <email, salt, iterations> without making the intruders job even easier.

I don't like to invent new security stuff, but I have had one idea. Basically I store <SHA512(email), salt, iterations> and then I store <PBKDF2(email, salt, iterations), UUID>.

That way they have to first dictionary attack the first table, and then use the results of that to do individual dictionary attacks on each row of the second table, which should slow things down.

Keep things simple, if you want anonymity, don't use email for logins.

Make your user generate an asymmetric key pair to authenticate to your system, call this the login key.

When the user want to post a message to your system, the user generates a new asymmetric key pair, call this the data key. The user would then sign their message with the data key and encrypt the private data key with their public login key addressed to themselves. The user would submit the encrypted private data key, the public data key, and the signed message.

To edit the posted message, your user downloads the encrypted data key, decrypt it with their private key. And then they sign the message with the private data key. Your system knows that the new message are generated by the same user as the original, because both messages are signed by the same public data key.

Be careful:

many implementations of asymmetric cryptography attaches the encrypting key's ID to an encrypted message, to make it easy for the recipient of a message to identify which key to use to decrypt the message. You want to make sure you encrypt the private data key without adding these metadata.
an attacker that manages to observe who downloaded which encrypted private key would be able to observe which user downloaded which key and make reasonable guess as to who is doing what. You can prevent this by forcing all users to download all encrypted private keys (or a reasonable chunk of it).

  Basically I store <SHA512(email), salt, iterations>

If you're storing the SHA512 of the users' email, wouldn't identifying the users be as easy as creating a SHA512 rainbow table?


What are the security risks to displaying an image loaded over http in a page loaded over https? I'm developing a PWA in which part of the app displays the content of emails to the user. However, many of the image URL's that are in the emails come from http domains, and therefore do not load in a PWA (because PWAs only load images that come from https domains).

A Google search revealed that to solve this, I would have to proxy all the images through my domain, so that they would be served over https.

But does that really make my connection any more secure? The image is the only thing loaded over HTTP at the moment, and if I proxyed it through my server, at some point it still has to come from the source server unencrypted (since the image isn't available in https).

I noticed that Gmail does proxy all images. So it seems like there must be some security benefit. I just can't think of what it would be.

The problems you will face with "mixed content" are many, and well documented.  For instance, see Google's own description.

Some simple examples are:

Session cookies may be sent in clear when fetching the image, if it is on the same domain (provided "secure" is not set)
Attackers may substitute the content loaded over HTTP with something malicious that executes in the same security context as the content loaded over HTTPS. This is more easily seen for Javascript, but similar problems exist for image formats as well (whether due to bugs or to the formats supporting scripting).


Understanding HTTPoxy I have been reading about the httpoxy exploit that exists because of CGI. Starting from this document I understood how httpoxy works.

My understanding: All the HTTP headers values need to be made available to the CGI programs and hence these values required for CGI are passed through environment variables.

For example: The path: header gets converted to HTTP_PATH environment variable.

Now comes the HTTP_PROXY. How does HTTP_PROXY environment variable will cause an attack?

Now comes the HTTP_PROXY. How does HTTP_PROXY environment variable will cause an attack?

It does not by itself cause an attack. But, the environment variable HTTP_PROXY is used by many applications to configure the proxy used for HTTP requests. And, since it is an environment variable it will be propagated to child processes too. This means that an external attacker can control the HTTP proxy to be used by internal code, i.e. the CGI script, PHP code itself or applications executed from within this code.

This can lead both to potential information leakage where sensitive data destined for internal applications are sent to the proxy controlled by the attacker. This can also cause the application to trust content fully controlled by the attacker (i.e. returned by the proxy) which then depending on the application can have various effects, for example executing code controlled by the remote attacker.


Securely store passwords in a mobile application Note : I'm posting this for a friend of mine who doesn't speak english very well... Well, I'm not so good myself, so excuse me in advance !

My friend's developing a Smartphone application, and they would like to have some advice to protect the IDs of the database.

The only idea we've got so far consists in :

All communications are done using asymmetric encryption (private key on the server)
The credentials are stored, encrypted, client side and the decryption key is stored server-side

When the application would need to use the credentials, it would ask the server for the decryption key.

Would that be secure?

Wouldn't we need to authenticate the client? I guess if we don't, it would be the same as sending the decryption key as plain text.

It smells like security by obfuscation. If the credentials are stored client side, and if the decryption key is sent to the client, an attacker could install the application on an emulator and through a debugger obtain the decryption key and the credentials. Ok, it is far from being simple but all depends on the value of the database.

A more common (and more secure) usage is to build a multi-tier application: the front app (on the smartphone) does not know the database but only communicate with a server. Here we authenticate the client with user+password, certificate or whatever... And only the server actually communicates with the database. That way the database credentials are never present on client and are never exchanged except on the server-database connection.

TL/DR: you proposal would actually make things harder for a possible attacker that would want to steal the database credential, but does not prevent all possibilities. Use multi-tier design for a really secure solution.


Public keys on OpenSSL vs PGP? It is my understanding that PGP permits multiple public keys, and in SSL you can only extract one public key? Is this correct? Is there any brief high level run down between the two. I don't feel as if I ever really understood how SSL works, and I'd love to get a better understanding.

PGP is format for encrypted and/or signed messages, and associated asymmetric key pair management, meant for emails. SSL (now known as TLS) is a protocol for establishing a secure bidirectional tunnel for binary data, over an existing insecure bidirectional tunnel for binary data.

So both systems apply to widely different situations, and they are hardly comparable. One common point, though, is that in both case one entity (the email sender for PGP, the SSL client for SSL) must obtain the public key of another entity (the email recipient, the SSL server) and use it. Let's call A and B, respectively, these two entities. In both cases, B can have several key pairs. However, the dynamics differs:

PGP works in an "email" situation. Email is one-way and one-shot. There is no dialog. A must be able to obtain enough information about B and its keys to produce the email, and B must know enough to process the incoming email without having to ask A for further data. This implies that A must obtain a copy of B's public key, and if there are several such keys, A chooses which key will be use.
SSL works for bidirectional connections. Client A and server B talk to each other, following a process called the "handshake", in which A and B agree on what cryptographic algorithms they will use (depending on what they both support and prefer). Specifically, the client announces what algorithms it supports (and in which order of preference), and then the server responds with the identifiers for the cryptographic algorithms that will be used. Then B sends its public key (in a certificate). If B has several keys, then B chooses the one which will be used (one which is compatible with the negotiated algorithms, of course).

That's the extent of the comparison between the two protocols: in PGP, sender/client chooses the key, which in SSL recipient/server gets to choose the key. Apart from that, they are too different in usage and context to be meaningfully compared.

See this answer for a primer on how SSL works.


Exchange Security - outgoing email marked as spam by recipients Our company emails are  getting blocked (blacklisted) every other day. Can someone tell us why the emails are getting blocked. And how to rectify for being blocked.
Your advise will be highly appreciated.

Some usual reasons (not a comprehensive list):

Your mail server is an open relay, anybody on the internet can use it to send emails to any address. Spammers very quickly find these and use them to spread spam. This way your server will get blacklisted in RBLs (see below).
Your server is used to send spam by its legitimate clients due to malware on your internal client computers. Check the mail queues and see what emails go through. This will also likely result in the server getting into RBLs.
Your mail server is in a black list (RBL) for any reason. Some recipients check if the sender server is in a blacklist and will either not take emails from that server or automatically mark them as spam. You can check whether your server is blacklisted here or here or here among others.
You are sending email on behalf of other domains apart from your own (the apparent sender of the email is not your domain). You should look into things like SPF and DKIM, also here.
Your server is in a dynamic IP range, meaning your internet provider marked your IP range as dynamic. Some recipient servers either don't take emails from dynamic IP ranges or mark them as spam.


Sign a lot of messages with same private key I'm creating platform where I need to sign a lot of messages (1k/sec), I want to use Ed25519 signature, because it has the best performance. Is it safe to sign that many messages with the same private key? Or it will have no impact in revealing private key?

It is completely safe to sign any number of messages with an Ed25519 private key. The only non-deterministic input is the hash of the message to be signed and the hash of the private key itself. The number of signatures that would need to be obtained in order to reveal the private key is likely to be so high that an attacker would be better off attempting to crack the key directly.


What is the purpose of frequently rotating TLS certificates without changing underlying keys? I read in the OWASP cheat sheet regarding certificate / public-key pinning that “Google rotates its certificates … about once a month … [but] the underlying public keys … remain static”.

Increasing the frequency of key rotation makes sense to me in that, should a key be compromised without detection, the time frame for ongoing damages is reduced.

What is the benefit of rotating certificates so frequently? Is it to allow them to use SHA1 (for old-browser compatibility) whilst limiting an adversary's scope for finding a matching signature? Or is there something else that I'm missing?

One big advantage is removing the need for revocation in the event of a compromise.

The "typical" way to do this is publishing a certificate revocation list (CRL) or using the OSCP protocol in the event of a compromise to revoke certificates. However, the CRL or OSCP check is incredibly easy to bypass. An attacker in a position to perform a MITM attack can simply block a client from communicating with the server where the CRL is hosted and the client will simply happily go about its business. This is necessary because of common situations like captive portals that work over HTTPS yet blocks all other traffic, including traffic to CRL servers.

Short lived certificates have the advantage that in the event of a compromise, the compromised certificate will only work for a very limited period of time until the certificate expires, therefore limiting the damage that can be caused.

Adam Langley has written extensively on the subject if further readings is required.


XSS for stealing cookies … not anymore? The other day I found a XSS vulnerability in a website that a friend told me to Pentest. It was a page from a school that he's managing, so the important thing here is the login credentials == COOKIES.

In this testing, I found that the cookies were HTTP Only, so I tested with a alert(document.cookie)  = The alert was blank.

I knew that the cookie was userSession and the value was 019845547 but I couldn't get it with XSS or JavaScript injection. I knew this information with the Developer Tools in Google Chrome.

I read that HTTP Only cookies cannot be accessed by JavaScript for security reasons and that's great!

But that means that XSS is not for cookie stealing anymore?

Or maybe I'm out of date for new security stuff?
Or is there another technique to steal HTTP Only cookies?

But that means that XSS is not for cookie stealing anymore?

In short, no, XSS isn't used to steal cookies when this flag is set.

The longer answer is that modern browsers support the HttpOnly flag on cookies. This flag can be set when the server sends a Set-Cookie header to the browser to keep document.cookie from getting the contents of cookies. It is a mitigation technique to the larger problem of XSS. As far as I am aware, with up-to-date browsers and current versions Flash, Java, and other plugins, there's no way to bypass this flag.

However, because you have XSS, there are other ways to get access to credentials without getting access to the cookies.


What does the HTTPS server verify when it asks for a client certificate? I assume that the only thing the server checks is whether the IP on the certificate matches the one for the current TCP/IP connection and that the certificate is signed by an authority the server trusts. Is this true?

I assume that the only thing the server checks, is that wether the IP on the certificate matches the one for the current TCP/IP connection, ...

That is very likely a thing the server does not check. Client certificates at least for HTTPS are usually not issued for a domain or IP, but for a user - because they are used to authenticate a user and not a system.

... that the certificate is signed by an authority the server trusts

This should be checked.
Additionally one might check for a specific subject of the certificate or the web application might decide based on the subject which user this is.


Decoding Gmail login I just noticed some a suspicious login into my Gmail account. When I check my login history, I see one entry that looks like:

  Access Type:
  Browser (Chrome)

  "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/55.0.2883.87 Safari/537.36,gzip(gfe),gzip(gfe)"

  (Browser, mobile, POP3, etc.) Location (IP address)   United States (CO) (2601:283:c200:8782:8039:dc84:e32c:513a)

It appears to be a Windows 7 login, which I do not own. The IP address given is foreign to me and I don't know how to decode it. Does anyone know?

I would like to change my password, but I think it is someone stalking me (someone I am in legal issues with currently, so I want to find out if it is actually that person).

There's nothing encoded in the log example, it's just a regular IPv6 address. According to db-ip.

  2601:283:c200:8782:8039:dc84:e32c:513a is an IPv6 address owned by Comcast Cable Communications and located in Pueblo, United States

If you are in a legal dispute and suspect being a victim of stalking, you should cooperate with your local authorities.


Mandatory to implement HTTPOnly if Java Secure Cookies are set to 'true'? Here is a test case from a recent application security asessment which I have had experienced:

cookie = new Cookie(strKey1, EncryptDecrypt.encrypt(strValue));
cookie.setMaxAge(-1);
cookie.setDomain(COOKIE_NEW_DOMAIN);
cookie.setPath("/");
cookie.setSecure(true); // for secure cookie by java
response.addCookie(cookie);

Although 'setSecure' is set to true, does this prevent attacks against attacks on the application via XSRF/CSRF/See-Surf or XSS/CSS or HTTPOnly has to be on HTTP headers!? or both?

HTTPOnly disallows the cookie from being read by JavaScript via document.coookie.

The Secure flag will restrict the cookie to HTTPS, but if your site has an XSS vulnerability, HTTPS will not protect you. The XSS URL https://example.com?q=<script>alert(document.cookie)</script> works just as well as http://example.com?q=<script>alert(document.cookie)</script>. Only the HTTPOnly flag will disallow script access to the cookie.


Can I see the MAC address of a router on an encrypted Wi-Fi network? Say that I am within range of a Wi-Fi network that is encrypted using WPA2, but I don't know the password. Is it possible for me to learn the MAC address of the Wi-Fi router that is broadcasting the network? If so, how?

Yes!
Using airodump you can look for WiFi networks around you. You can the look for devices on a specific WiFi network (this includes the router) by specifying the bssid. Your WiFi adapter should start finding devices connected to the AP.

Note: You need a WiFi adapter that supports monitor mode.
Here are the commands:

First we have to start our WiFi adapter card, go ahead and do

1.)
airmon-ng check kill
airmon-ng start [interface]

(The first commands kills all processes the might cause problems)
This will put your WiFi adapter card into monitor mode, letting you scan for WiFi networks. Your WiFi card should be renamed to something like mon0 or wlan0mon. Use this name in commands from now on.

2.)
airodump-ng [interface]

This command will start finding WiFi networks around you. Remember the BSSID of the WiFi network you want to look for devices on.

3.)
airodump-ng —bssid [bssid] -c [channel number, can be found when scanning for the network] [interface]

This command will scan on the WiFi network, it will look for devices connected to the AP. It should give you the MAC addresses of the devices connected, including the router.

That should do it! Forgive me for formatting mistakes as I am on my phone.


Does a user password protect against network attacks, or only physical? If I create a user in a Linux system with an empty password, does that expose any remote vulnerabilities, or is it only a problem if someone gains physical access to the machine?

If I create a user in a Linux system with an empty password, does that expose any remote vulnerabilities, or is it only a problem if someone gains physical access to the machine?

It does not expose a remote vulnerability, it is considered a misconfiguration which depends on:

Your SSH configuration. Per default PermitEmptyPasswords is set to no in /etc/ssh/sshd_config.
How the user itself is configured. If the user is allowed shell access or not which can be seen in /etc/passwd.

Assuming that both 1 and 2 apply, you need console (physical) access to your machine in order for this user to be able to login.

There should only be one reason for not setting a user's password and that's when public key authentication is configured. To avoid any confusion, there is a difference between user accounts (uid >= 1000) and service accounts (uid < 1000).


How to bypass PHP strings == comparison for sha256 string? I already know about PHP strings == comparison vulnerabilities

http://marcosvalle.github.io/ctf/php/2016/05/12/php-comparison-vlun.html
https://www.owasp.org/images/6/6b/PHPMagicTricks-TypeJuggling.pdf
https://hydrasky.com/network-security/php-string-comparison-vulnerabilities/

But I can not find the way to bypass == comparison for sha256 string.
Below is the example code:

$username = $mysqli->real_escape_string($_POST['username']);
$password = $mysqli->real_escape_string(hash("sha256", $_POST['password']));

$UserDB = $mysqli->query("SELECT * FROM Database")->fetch_assoc()['value'];
$PwDB = $mysqli->query("SELECT * FROM Database")->fetch_assoc()['value'];

if($UserDB == $username){
    if($PwDB == $password){
        $_SESSION['admin'] = "Admin_".$username."_Password_".$password;
        header("Location: admin.php");
        exit;
    } else {
        $content .= alert("danger", "Password is wrong.");
    }
} else {
    $content .= alert("danger", "Username is wrong.");
}

Do you have any ideas to bypass sha256 password?

This is exploitable in some cases. The root issue here is the way PHP type juggles when comparing values with the double equal operator. If the values compared begin with "0e" or "00e", etc, they will be juggled to a float and compared as two zeros. The following snippet illustrates this:
php -r 'if ("0e123" == "00000e228") { print "You win\n"; }'
As the user supplied password is hashed without a salt you can control the $password value of the comparison, however the $PwDB value is presumably from the database itself and an unknown value. In order for the comparison to equal true you would need two things:

submit a known value that results in a suitable hash value when hashed with sha256. Luckily the internet has already solved this we can take 34250003024812 ( from https://github.com/spaze/hashes/blob/master/sha256.md)

A valid username for a user who's hashed password in the database starts with the magic 0e type string.

So in short, use a wordlist or enumerated usernames and attempt to login with the password 34250003024812 for each of them. If you're lucky it will match one or more users.


Is online banking more secure on iOS than a desktop computer? Does Apple's iOS provide a more secure environment for online commerce (banking or shopping) than Windows or Mac OS X? Since the only software that can run on iOS must be vetted by Apple, the likelihood of running malware on the device is much lower. And even if malware is running on the device, I assume it wouldn't have the same capabilities that desktop malware does, such as keylogging.

Furthermore, iOS Safari doesn't support plugins that would enable a man-in-the-browser attack. This means that drive-by malware installation through common vectors such as Java, Flash, and Adobe Reader should be impossible. It presents a user interface that clearly indicates whether or not a connection is secure, and that user interface cannot be overridden by the site being displayed.

Assumptions

iPhone has not been jailbroken.
The password is typed with the onscreen keyboard.

Extra credit

Does use of a password manager (like 1Password) improve or reduce security?

If you are using an IOS mobile device, your device is subject to many attacks such as

Juice jacking
A web browser that doesn't show HTTPS status clearly (iPhone)
A web browser that doesn't show the URL... enabling phishing (iPhone)
Web browsers that don't support additional SSL/TLS validation software such as Convergence

If you must use a mobile device, I'd suggest using a dedicated application, as this post suggests.  In addition, the application itself may also validate the HTTPS certificate key (preventing MITM attacks) or even better it may use mutual auth TLS

(The following is similar to @Rory's answer:)

The ideal solution, is to reformat your PC, and install a virtual OS for games, testing, etc.  Then use the standard PC for all your banking needs.  Since the VM can't access your PC (hopefully you configured it so) then you're safe from any phishing or other attack.*

*  Exception


Hops encountered More for spam Mails than Legitimate Mails Background

I am working with email headers for spam detection. Each E-Mail header contains many "Received:" headers fields. Each "Received:" header is added by an intermediate Smtp/Mail server in the path from the origin of the e-mail to its destination.

I read in a research paper that the number of intermediate Smtp/Mail server encountered in that path is high for legitimate mail and less for spam mail.

Here is the explanation provided: "spammers have exploited a predefined relay servers for delivering their spam, so the number of hops is limited, while in the normal case the number of relay servers may vary according to the paths the message follow to reach its final destination."

Thoughts:

The path of normal mail would be: Mail User Agent, to sender's Mail Transport Agent, to destination Mail Transport Agent (IP obtained by MX Query) or chain of destination Mail Transport Agents inside the destination domain.

For spam mail, the path should be: spammer to open relay server, open relay to destination MTA, or chain of destination Mail Transport Agents inside the destination domain.

So,the hops encountered would be nearly same.

Query:

Can someone explain if the above analysis is correct? How it is that number of hops encountered by legitimate mails are more compared to spam mails and why the research says "spammers have exploited a predefined relay servers for delivering their spam, so the number of hops is limited"

This is probably correct in a statistical sense. A legitimate e-mail will probably (but not certainly) go through several hops not only on the destination side (which are mostly always the same for a given recipient, so that number is not interesting) but also on the sending side, and these will be recorded in Received headers.

A spam, however, while sent by a relay, is often sent by a non-smtp relay or by a trojan on an infected PC. These vectors will not add Received headers. The spam will only have Received headers if it is relayed through a legitimate server (there are several advantages and disadvantages to doing that, it is not a very common choice as far as I can see) or if the spammer wilfully adds fake Received headers in an effort to confuse people or anti-spam programs that try to analyze the headers (and that is passably common).

So, statistically it does not surprise me that spams on average have less Received headers than legitimate mails. However, apart from adding this to some Bayes filter criteria in a sufficiently low-profile way that the major spammers out there do not start adding masses of fake Received headers to their junk, I don't really see a way you can make use of this insight.


What firewall settings on a Macintosh are the most restrictive, while still permitting casual internet use? I don't want this to be subjective, so I'll try to make the requirements as clear as possible.

On a Mac with Snow Leopard, how can I set up the firewall rulesets that allow ONLY:

Using the internet through standard browsers (Safari, Chrome, Firefox), software updates, Skype, iTunes, and ftp access to upload data to a web site.

No need for Mobile Me, iCal, address book, iChat, etc.

If the ftp access presents a big hole in the firewall, then I'd rather use a separate PC to do the uploading, but I think I can simply open the port for that, correct?

So basically, everything else is blocked.

An example of rulesets I'm looking for is: ipv4, deny ip from 127.0.0.0/8 to any in, for both ivp4 and ivp6.

I've read through much of the documentation for the firewall, and searched through information on several sites,  but it's all very cryptic to a security noob.

Go buy Little Snitch http://www.obdev.at/products/littlesnitch/index.html for $30.

  Little Snitch informs you whenever a program attempts to establish an outgoing Internet connection. You can then choose to allow or deny this connection, or define a rule how to handle similar, future connection attempts. This reliably prevents private data from being sent out without your knowledge. Little Snitch runs inconspicuously in the background and it can also detect network related activity of viruses, trojans and other malware

And in your System Preferences | Security | Firewall, ensure your Firewall is on, select Advanced and checkmark "Block all incoming connections".

For ultra-paranoid surfing, buy VMware Fusion (http://www.vmware.com/products/fusion/), install your OS of choice in a virtual machine and use that for surfing.  After a round of browsing in the dark, you can hit revert to restore your virtual machine to its virgin state.  You could also build several virtual machines and use the appropriate one for the tasks at hand (e.g. virtual system A for when you do banking activities, virtual system X for when you do dastardly activities).


ISO27001 Certification - Business Incident We have a defined and certified scope. If we have a business event that impacts the services or a building that is "in" scope and we have to shut that building down and recover services to another site that does not have an equitable set of physical and logical security controls how does that impact the validity of the certification?

Do we need to notify the auditor?
Can we simply work on corrective actions to ensure that at the next audit we are aligned with the standard and control operation?
Is there anything else we need to do?

27001 certification is about your ISMS, not your controls. If a control stops working, it doesn't impact your certification.

Of course, if a control stops working, and your ISMS doesn't detect and fix that problem, then that impacts your certification....


How safe is the ownCloud encryption in a trusted LAN? ownCloud looks like a promising locally hosted dropbox alternative. However, it has been pointed out that the encryption is not exactly strong... (The ownCloud team does at least provide a list of problems themselves) But assuming I'm running an ownCloud server in a trusted LAN, is the stored data safe enough to withstand physical theft of the unpowered server? With "safe enough" I mean compared to e.g. a unmounted TrueCrypt volume.

Pascal's blog entry shows a few weaknesses, some of which being recalled in ownCloud's advisory, but they did not recall the worst.

The storage of encryption keys as files in /tmp is already pretty bad, especially since /tmp is a true disk-based directory in many Linux and *BSD operating system (I usually configure my /tmp to be a memory-based filesystem, but this is not the default). Therefore, some encryption keys will make it to physical storage. And it is well-known that deleting a file does not wipe the data out; it merely marks the corresponding blocks as reusable. Data is not written over until some new files are created. Thus, it can be assumed that some keys will leak if the unpowered server is stolen.

The worst weakness is about key generation. Pascal states it as:

  The computation of the overall entropy, and thus the effort to guess a key, is left to the reader… Not to mention the maximal achievable amount of  4*log2(99999-10000+1) = 65.8 bits of entropy, which are far from the recommended minimal value of 80 bits.

The bit about "65.8 bits" is misleading: it means that the way ownCloud generates keys implies a maximum entropy of that amount... assuming that the involved PRNG are perfect. But they're not. The 65.8 comes from the key production as four integers in the 10000..99999 range. But they come from a Mersenne twister PRNG, itself seeded with another PRNG, which is in turn seeded from the current time and the thread identifier. The time is taken to the microsecond; let's assume that the attacker knows that time with one-second accuracy. Let's also assume a 16-bit thread identifier. That's, at best, 36 bits of entropy. A mere PC will wade through that in a matter of, at worst, a few hours (encryption uses Blowfish, which has a rather expensive key schedule, but not that expensive).

Of course, since there is a password involved, attacking the password is probably even easier, but this low-entropy key generation prevents strengthening from a big, random password. This is rather hopeless. If the Mersenne twister was replaced with a decent, cryptographically strong PRNG with appropriate seeding (e.g. simply reading from /dev/urandom), then the other weaknesses would be sources of serious concern, but the weak seeding trumps everything.


Why http cookies are automatically sent to the server upon a http requests and CSRF On the client side, a http request sent from webpage A that targets website B will cause all cookies belonging to Website B to be sent to B (even when A does not belong to B).

I do not understand why the cookies behavior has been designed this way. Isn't it obviously insure and the root reason behind CSRF (cross-site request forgery)?

I know nowadays "same-site cookie" is on the way. But I want to know what was the motivation of the old insecure design.

According to Wikipedia, the concept of cookies comes from Lou Montulli in June 1994. The HTTP protocol was still very young.

Since HTTP lacks some fundamental security features, such as encryption, I guess security wasn't their priority. I also doubt that any of the people working at that time could have anticipated that HTTP would be so wildly used nowadays, even by evil actors.

It's way easier to look back at all the vulnerabilities / specs flaws we found in the latest 20 years, that to anticipate them all in the first place.

As you've said, the SameSite cookie attribute is on the way to fix that flaw. Until its support by browsers, developers should use standard CSRF mitigations techniques.


Are packets processed by a proxy new or modified? Client ---> First packet ---> Proxy ---> New packet? ---> Server

If we speak about proxy systems, does the first packet get discarded and a new packet gets created, or it's still the same packet (TTL gets decreased) any only the Layer 2 addressing gets changed? So if the L2 addressing gets changed do we speak about a new "packet"/"frame"? What if SSL/TLS is involved?

When using a proxy there is one connection between client and proxy and another connection between proxy and server. These connections are usually fully independent regarding TTL, TCP flow control, packet size (when using TCP) etc. Often they also have different source and destination IP and ports, i.e. with an explicit proxy the target of the connection from the server is the proxy, the target of the connection to the server is the server (different from proxy) and the source of this connection is the proxy (and not the client). Even the application layer content might be different, for example by injecting X-Forwarded-For headers into the original HTTP request when forwarding the request or Via headers into request and response.

Some proxies explicitly extract packet layer information from the source connection and apply these to the target connection when forwarding the data. Often this is the destination IP address when the proxy is configured to be used in a destination transparent way. It could also be source IP (and port) if the proxy is used in a fully transparent way (destination and source transparency). It might in theory also be possible to extract the original TTL and apply it when forwarding  but I'm not aware of any proxy doing this.

With SSL/TLS involved the situation is no different. If SSL interception is done then there is one SSL connection from client to proxy and another one from proxy to server so that the proxy can get the plain text data. If no SSL interception is done then there are still two TCP connections but the proxy will forward the encrypted data directly.

Note that the behavior of a proxy as used in an application layer gateway as described above is different from Deep Packet Inspection (DPI) as done in many Next Generation Firewalls (but not all, some employ proxies). With DPI the original packet gets forwarded which includes the same source and IP address and port and also TTL. SSL interception is not possible this way, i.e. for this the firewalls also employ (transparent) proxy technologies with one SSL connection between client and firewall and another one between firewall and server.


Flaws in my proposed license verification system? in my firm, most of the software is secured by a couple of different antiquated licensing systems. For example, after setup the user has to start another program that tells him his calculated machine id. He needs to send us this id, which is embedded in a file, encrypted and shipped with another setup, that just copies the file in the relevant folder. Not only does this generate a lot of workload and a hurdle for the user, the decryption key needs to be embedded in our software and can easily be extracted, allowing the user to circumvent this "security" measure.

After developing my first application for this company, I would like to develop a prototype for a more advanced licensing system with my own service. I'm looking to run my general plan by you, I'm sure I've overlooked some things and would like to have them pointed out before bringing it to management..

Plan:

Client automatically receives a license key after registration
Client enters this license key into my application
Application sends this key with machine information and sends a GET_LICENSE request to our server
Server checks if license key is in our system and returns a pgp encrypted message to client
Client uses its embedded public key to check the license file and the sign date (which should be secure, (as long it was signed on our side](http://www.pgp.net/pgpnet/pgp-faq/pgp-faq-message-signatures.html))
If there is no internet connection, start the application if license file is available and sign date is not older than n days
Update the license file every time a internet connection is made

Now I realize there is no complete safety, but this should give us a lot more security and benefit our honest customers with a more comfortable experience than before. A internet connection would only be required on first start and then every other day, but our application already needs a connection for most tasks. We would save the man hours for the manual license creation and communication with the customer while allowing him to sign up and use our application no matter of our office hours and availability. No credential information could be extracted from our application.

Cons?

Your design is the basically the same as most licensing systems. One extra step is to obfuscate your application, so it is more difficult to decompile.

How secure is this? It will certainly hinder a typical user. In fact, even the older system with an embedded key will stop most users. While you say it is easy to extract the key, that is from the point of view of a skilled programmer, not a typical user.

It will not stop a skilled cracker. While they cannot create a fake license file, what they can do is modify the application binary and remove the code that checks for the license. Obfuscation makes this harder, but no obfuscation is foolproof.

The real concern though is that it only takes one skilled cracker to break your application, and they can then put the cracked version on Bittorrent. This may not be the end of the world. Many people will still buy the official version. Perhaps they're just honest, or don't know how to find cracked software, and a lot of people are rightly concerned about viruses coming with cracked software.

Ultimately, while your change is a security improvement, I don't think it makes a material difference to whether your software can be cracked. It does however sound like an excellent usability improvement.


SQL injection explanation I just found in logs that someone try to exectue this SQL injection

/commands.php?id=-1+union+select+0x6c6f67696e70776e7a,0x6c6f67696e70776e7a,0x6c6f67696e70776e7a,0x6c6f67696e70776e7a,0x6c6f67696e70776e7a,0x6c6f67696e70776e7a,0x6c6f67696e70776e7a,0x6c6f67696e70776e7a,0x6c6f67696e70776e7a,0x6c6f67696e70776e7a

anybody know what he/she wated to do? Is it valid? Anybody know how to decode those hex strings?

It's trying to see if that page is vulnerable to sql injection. It uses id=-1 to make the original query return no results so the union is executed (since usually only the first record is fetched). If the union is executed, the attacker will find 'loginpwnz' in the returned page (the hex is to avoid using quotes, which might be escaped).

Since the union select must return the same exact number of columns, the attacker is probably trying from 1 to n columns.


Have I been hacked? Terminal shows me in a different hostname than my machine Sorry for the generic title but really don't know how to call this.
I've just upgraded my MacBook Air to macOS Mojave 10.14.3.
Usually, when opening the terminal it would show something like myusername at myMacBookAir in ~.

After this upgrade, but actually, I can't tell for sure if it was happening even before, it started showing myusername at DESKTOP-GD4U33R in ~. I tried to google DESKTOP-GD4U33R but got no results, so I tried to open a browser tab at http://desktop-gd4u33r/ and magically a webpage showed up (the one below).

Another curious thing is that if I turn WiFi off and reopen the terminal it goes back to normal, myusername at myMacBookAir in ~ is shown.
When I turn it back on this DESKTOP-GD4U33R appears again. To me (being a web developer) seems that I have a webserver running, but I don't even have this Bitnami WAPP installed, so I'm seriously thinking there's something malicious on my machine.
Any help is much appreciated.

If you were unaware you can do local DNS resolution by modifying /etc/hosts this file looks something like:

127.0.0.1     localhost
192.168.1.2   DESKTOP-GD4U33R

So, this can be done for many legitimate reasons, as a local DNS lookup may be more favourable. Do realise that the localhost (127.0.0.1) is a loopback address; it is accessible via your machine only. A localhost lookup could be favourable if you were doing web server testing locally before deployment and hence needed privacy.
Mentioning your hostname changed from user@MacBookAir ~ to user@DESKTOP-GD4U33R ~ implies an application with root privileges made this change (I speak more about this below). Issue cat /etc/hostname will allow you to view your hostname. You can change your hostname either by editing /etc/hostname or in Settings > Network Utility. By default modern, Microsoft Windows machines use the hostname @DESKTOP-XXXXXXX where X is a random base-36 string of upper case letters and numeric characters. Just a suggestion for the possible naming convention, as it's quite specific, but as for your hostname becoming DESKTOP-GD4U33R and having a DNS resolution to DESKTOP-GD4U33R via 192.168.1.2 does seem quite unusual.
This is good news as the IP address resolves to your local network. Consequently, this potential threat is isolated. As mentioned identify who 192.168.1.2 is before proceeding further. But, I would suggest, presuming you are the network administrator or are authorised, using NMap to identify open ports on this machine; nmap -Pn -A 192.168.1.2 will suffice. This device can absolutely be an egress port on your machine, from terminal use ifconfig | grep 192.168.1.2 you can identify if this IP address is one of the machine's network interfaces.
ClamAV offers a macOS antivirus, but locally this looks more like an application modified /etc/hostname and /etc/hosts. It could also be worthwhile ensuring both files are read-only ls -l /etc/hostname; ls -l /etc/hosts should return something like:
-rw-r--r-- root root  /etc/hosts
-rw-r--r-- root root  /etc/hostname

Notice that only the root user (not group) should have write access.


Can my IT admin see websites I hit via VPN I have access to a VPN network while I'm in my office. If I'm in the VPN I can access sites that my office network has blocked. Can the IT admins see that I'm going to those sites? And if so at what part of the network is it visible?

It really depends on what you really mean. Can they see what is in the packets? Probably not. Can they see that the traffic is encrypted and you are using a VPN? More than likely. Can they see your browser history? I would say it is safe to assume they would be able to. So in short, yes but not at the network level.


How is encryption different for Windows yet they are identical? I right clicked on C:\Users\USERNAME and did advanced -> enable encryption.

On one laptop it turned green. The other it shows an icon on the files with a lock.

What is the difference between these?

Both are factory installs with Windows 10. They are identical. Niether have TPM chips. They both have 1TB HDDs. They bother were ordered at the same time.

They were Dell Inspirions 5548.

I did the exact same procedure though by doing properties -> advanced -> enable encryption for both laptops yet they yeilded different results

LAPTOP1:
[

LAPTOP2:

The green folders are encrypted, the locked folders are locked to the user only(possibly password protected, but not encrypted). A quick google search for folder with lock icons windows 10 shows that they can only be accessed by you, and not anyone else. Green on the other hand means actually encrypted.

A simple test: Send the peglocked folder to someone else(a different user on the same system is fine as well as long as they are the one who downloads it)(through email or some such) and see if they can open it. If so it means it was just user locked, and only the owner on that machine can access it(stupid, but shareable). If they can't and they  get prompted for a password, then it's at least password protected. If you can open it with an OS that will ignore the password and view the contents correctly, then it was just passworded on Windows and not encrypted.

If you weren't prompted to create a key for it, and back it up, it wasn't encrypted. It was just locked or possibly password protected.


Why should class names be whitelisted? I am using the Accept known good validation strategy to sanitize user input (rich HTML) and are using a 3rd party component to do this.

The component by default requires every permitted class name to explicitly listed, but also has a checkbox to suspend this rule (i.e. every class name will be accepted).  The help text for this checkbox says:

  Bypassing this rule may lead to security vulnerabilities. Only grant this filter to trusted roles.

I understand by checking that box, I would permit user input such as:

…

However, I am unable to think of what to replace "exploit" with that may be a security vulnerability.

Can anyone explain to me why I need to whitelist class names.

The problem is when user-specified HTML is included together with your own HTML and application logic on the same page. It is common that the application logic depends on the content or location of specific elements inside the HTML which are selected based on id or class name. If you allow the user to specify any class name an attacker might be able to generate content with the same class names as used in your application logic. This might severely confuse the application logic which might lead to security issues.


How to ensure that passwords are not copied? We are developing a password vault solution which gives a web service based API for fetching password from our vault. The API consumers will authenticate by supplying valid credentials and will request for username and password for an IPAddress. How can we ensure that our API consumers have not stored or relayed the password further ? Is there a way to copy-protect passwords ?

We are using WCF over https for exposing our web service APIs.

You cannot copy protect passwords. The only thing you can do is give the passwords a very limited lifetime. After that lifetime, the password is changed and the consumer needs to request a new one.


Is there a difference in terminology between the words "cryptogram" and "ciphertext"? I've noticed that certain security professionals use the term "ciphertext" while others use "cryptogram".  Is there any meaningful difference between those terms?  Or can they be used interchangeably?

They're grammatically different for sure, because cryptogram is exclusively a count noun, while ciphertext can be either a count or a mass noun.

Also, I can document that the term cryptogram is sometimes used in senses where it's definitely not synonymous with ciphertext.  For example, in the v2.2 specification of the Keyak cipher (a candidate in the ongoing CAESAR competition), p. 3:

  The mode Motorist supports the authenticated encryption of sequences of messages in sessions. During a session, it processes messages and cryptograms. A message consists of a plaintext and possible associated data (called metadata in the remainder of this document).  For each message, it wraps it by enciphering the plaintext into a ciphertext and computing a tag over the full sequence of messages. A cryptogram consists of a ciphertext, possible metadata and a tag. For each cryptogram, it unwraps it by deciphering the ciphertext into a plaintext, verifying the tag, and returning the plaintext if the tag is valid. A message can also consist of metadata alone and the corresponding cryptogram does not have any ciphertext.

Clearly the authors here use ciphertext and cryptogram in different senses.  The last sentence tells us that in their usage, there is such a thing as a cryptogram without any ciphertext.

I certainly don't mean to imply that this is by any means an universally accepted usage, however.  In many fields, different authors often use slightly different definitions of the same terms.  The best advice is to always try to discern the authors' meaning in the context they use the terms, and not to try to impose some external definition they might not be heeding.

So perhaps counterintuitively, the answer is "yes" to both of your questions:

  Is there any meaningful difference between those terms? Or can they be used interchangeably?

There are many contexts, perhaps even most, where the choice between those two words doesn't matter.  And a few contexts where it does, like the Keyak specification.


What is the use of client.pfx and server.pfx? When I am trying to call a third-party Api, I am given 3 files generated by the Api site: root.cer, client.pfx and server.pfx.

I am using Windows system so I installed root.cert in Trusted Root Certification Authorities using mmc (Microsoft Management Tool). I know by this step I installed a CA in my machine but I still cannot call the Api from my machine. So I also installed client.pfx in personal mmc too and after that I am able to call Api sucessfully.

I am confused that what is the use of client.pfx. Here is my understanding of the whole process:
I know I am trying to connect to Api site by SSL/TLS. Every time I connect to the site, it will provide a certificate and then I verify the certificate by CA I installed in my machine using root.cert. After that, I am able to confirm the public key belongs to the site to which I am trying to connect and then I should be able to send messages encrypted by the public key to the site.

My questions are:

What is use of file client.pfx and why I must install that?
What is use of file server.pfx that is not used in the my scenario?

what is use of file client.pfx and why I must install that?

SSL/TLS uses (almost always) server certificates to authenticate the server (which you validate using the root.cert). It can also optionally require that the client authenticates against the server using a certificate (mutual authentication). This is done in your case and the client.pfx file contains the client certificate and the associated private key. Only the client showing that it owns this certificate is accepted by the server.

  what is use of file server.pfx that is not used in the my scenario?

This is probably the certificate for the server. I have no idea why you were given this file (since you shouldn't need or have access to the servers private key) but you might use the servers certificate to make your application only accept this specific certificate for the server and not all certificates issued by the CA which match the servers name. This is also called certificate pinning or public key pinning.


Collecting credit card info in HTTPS iframe within an HTTP site slate.com's paid membership program collects credit card info inside an HTTPS iframe over plain HTTP . The HTTPS url is https://my.slate.com/subscriptions/manage/.

In an article, they claim this is safe:

  When credit card data are submitted, they are sent to a third-party payment provider and your credit card data are not stored by Slate itself. Your credit card data are always sent over HTTPS. I assure you that entering your credit card information at Slate is a very safe thing to do and I hope that you enjoy Slate Plus.

However, they also take username/password over plain HTTP so I am skeptical.

Could someone tell me if it is possible to securely get credit card information in the way they have described?

What they are doing is certainly better than not doing https at all.  However, their external http page is more susceptible to attacks like Man-In-The-Middle that could cause the 'secure' iFrame to be replaced or compromised in other ways.  This method makes it hard for end users to make their own determinations, too - the lock icon is helpful and browsers are working hard to teach the users how to determine if a site is safe.

Given the minimal cost of https now and given how much additional security it offers in general, there's no reason for them to defend this - they should just fix it and go https everywhere.


mail.ru and slightsearch.ru hijacking browser default search engine set by admin I recently got malware installed on my PC that contained software that infected my google chrome, by hijacking my default search engine. I tried:

Removing newly installed programs from PC, using windows utility.
Using Microsoft essentials and hitman pro to fully scan my computer (removed  3 malware of which one was a program and the other adware)
Removing the newly created extension in google chrome.

I tried to change my search engine back to default but I states that the administrator of the program has rights to change the search engine. I then:

Reset my chrome, and restarted my PC. Didn't work.
Then went to registry and deleted all traces of slightsearch and any keys relating to default search engine of chrome.

Restarted PC and nothing has changed at all. My home page is working as normal and I can search google when searching using the URL bar then it redirects to slightsearch.

Lastly, this malware even stared showing me ads on my desktop, when not in Chrome. Scanning and removing the malicious files solved this issue, but the search engine issue still exists.

Please help me solve this issue. And with all due respect, please do not give me the usual tips for removing popups or adware, because as already stated I have done all of these steps. Will appreciate any new solutions.

Regards

Ok so I eventually fixed the problem.

I had to delete files under c:\Windows\System32\GroupPolicyUsers

Checked all the files contained in GroupPolicyUsers and then deleted those that related to chrome and that was messing with my Registry.

Restarted chrome and now all is fixed!


Is it possible to create GnuPG keys from a x509 cert/key pair? I have a digital cert issued by my organization for signing email. It's imported into Thunderbird and the key and cert can be exported to a .p12 from within Thunderbird.

I'd like to use the .p12 to generate a GnuPG key pair for use with the Thunderbird Enigmail extension. Is this possible to do or are the technologies just way to different.

I've been able to export both the private key and cert to x509 certs. I've imported the private key to GnuPG via gpgsm. If I issue gpgsm --list-secret-keys, I get (some info redacted):

$ gpgsm --list-secret-keys
/home/use/.gnupg/pubring.kbx
--------------------------------
           ID: 0xFFFFFFFFAxxx
          S/N: 00C2A8Exxx
       Issuer: /CN=COMODO SHA-256 Client Authentication and Secure Email CA/O=COMODO CA Limited/L=Salford/ST=Greater Manchester/C=GB
      Subject: /CN=xxx/.../C=US/EMail=user@domain.com/...
          aka: useralias@domain.com
          aka: user@domain.com
     validity: 2017-03-28 00:00:00 through 2020-03-27 23:59:59
     key type: 2048 bit RSA
    key usage: digitalSignature keyEncipherment
ext key usage: emailProtection (suggested), clientAuth (suggested)
     policies: 1.3.6.1.4.1.6449.1.2.1.3.5:N:
  fingerprint: B2:8F:37:BA:xxx

Do I need to import the public key into gnupg as well? It doesn't show up when I do --list-keys. Also, do I then need to export the key pair from GnuPG for use with Enigmail?

While X.509 and OpenPGP share the same cryptographic algorithms, both have incompatible formats and certification/trust models (hierarchical vs. web of trust). Theoretically you could convert the keys between the formats, but you would lose certificates on the key and still could not use the key to communicate with people using the other system. You would still handle the keys as a completely different key pair, but at the same time expose it to issues in both systems/implementations.

gpgsm is a GnuPG implementation of GnuPG, but not supported by Thunderbird and Enigmail. As you already realized, Thunderbird has built-in support for X.509 -- you can manage the keys in the preferences (Advanced, then Certificates).


Why should I use whitelist on a WAF? I was studying different WAFs, from open-source (such as ModSecurity and NAXSI) to commercial solutions (Imperva, Citrix, Fortinet, etc.). Many people state that having a whitelist-based WAF is far more efficient than blacklist.

I basically understand why a blacklist can be obsolete (even if in the case of bots it can be pretty good), and how a whitelist resolves those issues. But it’s difficult to find a detailed explanation of why whitelists should be used instead of blacklists.

Question: Why I should use whitelist instead of blacklist with a WAF?

Explanations and/or links to papers would be most welcome.

Blacklisting is good if you have omniscient knowledge of every single vulnerability that could ever exist for a single product. I am assuming you do not have infinite knowledge, so you'd be in a constant fight to blacklist the next threats.

A whitelist is good if you have the expected behaviour and inputs for a product. Eg. you expect users to visit the site and input numbers in a text box. You restrict the text box input to numbers only, so all possible exploits involving letters and symbols are explicitly disallowed.

Whitelists can protect you from the future. Blacklists can protect you from the past.


DynDNS alongside Tor? Is there a way to resolve Dynamic DNS with Tor so that I can connect to my computer behind a NAT even if I am in a country that consider supicious connections to my native country ?

DynDNS does not differ from standard DNS in any way.

The issue with Tor is that it only handles TCP, while DNS query usually relies on UDP protocol. Due to this, without further precaution, DNS resolution queries will be sent outside of the Tor tunnel.

You should therefore use a specific distribution, like Tails or Whonix, which will ensure that all your traffic including DNS queries will be sent through Tor (these are live-systems, you can boot your computer from them or use them inside a virtual machine).


Decryping a RAR file with same password I came across a problem very similar recently and wondered if anyone knew how to solve this.

So say for example I have an RAR archive called archiveA.rar and a password to protect it the password is known as keyA.  keyA is stored on the server but I can send the server any file and it will compress it into a RAR file and encrypt it with keyA.  I can keep sending files to the server to retrieve encrypted versions of different files.  So my question is with all this given information and the fact that I can send unlimited files to the server can I solve for keyA, if so please explain how I would do so?

RAR uses AES256 for encryptionsource, thus the question is whether AES is cryptographically resistant to a known-plaintext attack.

At present there is no known method that allows retrieving AES encryption key given unlimited number of plaintext inputs and corresponding outputs faster than brute-force. Although there is no proof that it is impossible.

See related posts on Cryptography SE.


Hardware security key with locked down usb slots I would like to use hardware security keys in an environment where it is additionally needed to lock down any ways in which a user could download data to a device like a usb key. Is it possible to lock down a usb slot in a way, that file transfer is not possible but hardware security keys still work?

In my case the scenario would include Windows 10 Pro as an OS and preferably a fido2 capable key.

Yes, it is possible. It will reduce security, but may still be good enough.

U2F devices appear as a HID device. That's a USB class for keyboards and mice. USB storage devices appear as USB storage devices.

You can disable one class in your OS, e.g. disable USB storage (and UAS), but allow HID.


How could the Chinese Communications Authority find a backdoor on my website? I host a legacy HTTP website on my own hardware in China. It was attacked due to the Struts file upload flaw last month. But yesterday, Communications Authority in my province alarmed me, there is still a backdoor on my website, and I need to clean it. Here is the information they gave me:

Backdoor script URL: http://my.website.com/images/xxx.jsp
My IP address and port: 1.1.1.1:80
Hacker's IP address and port: 2.2.2.2:2000

After that I confirmed they are correct, there is a backdoor script.
However frankly, I am worrying more about them than some random hackers from internet due to there reputation. So I try to learn how they know that. Here is my assumption:

The hacker's IP already reported, I can find it in this blacklist:  https://cleantalk.org/blacklists/1.1.1.1 for example. And they also know this list.
They filtered all packages to that IP address, and get the backdoor script URL from the HTTP headers in that packages.

My questions are:

Is my assumption correct?
If it is a HTTPS website, could they still get the URL?

While it is hard to know what they did exactly I expect that they simply watch services like Phishtank or URLhaus or might also have access to the results of scanning infrastructure as needed for Google SafeBrowsing or Microsoft Smartscreen (Baidu might have similar services) or that the URL was reported to them as suspicious.
None of this requires them to do expensive traffic analysis or to even break HTTPS.


Why are .URL and .WSH files considered dangerous? Why are windows files with the extension ".url" and ".wsh" considered dangerous (e.g. blocked by many mail filters)? The way I see it:

.URL: you can link to a malicious website which serves an exploit, but it is even easier to type said url in a mail message? You can link to a local file, but you can't pass any arguments to a local file.
.WSH: you can link to a local script. A WSH file on itself can't do anything harmfull. You can't pass any argument to an existing script on the windows system.

.url may lead the use to click and redirect to website that host malicious exploit code, e.g. execute exploit code on installed unpatched software.

Blocking of WSH is similar to blocking autorun.inf
Sample .WSH  file from this question.

[ScriptFile]
Path=C:\WINNT\Samples\WSH\showprop.vbs
[Options]
Timeout=0
DisplayLogo=1
BatchMode=0


Is it safe to download an HTML file on an unknown website using something like Python's urllib.urlretrieve? I know that some sites can infect you with malware just from visiting them. Is this because they run JavaScript in your browser? So would merely downloading the HTML and not running its JavaScript be safe? Are there other attack vectors to worry about?

If a site uses a JavaScript-based exploit, then not executing the JavaScript code will indeed mitigate that exploit.

Note that (1) not all browser attacks are JavaScript-based, for example pure HTML or CSS could also be used, and (2) any code or library you use can have other vulnerabilities, though the odds of them being prepared for such a random library being used are very slim, so it's almost certainly fine.


What is Samba in simple terms? Well basically a couple of days ago I decided to go on Omegle and one of the people I met seemed to be a troll and some point said why is my Samba protocol open.

From this site they were able to get my IP.

However my only concern here is that can they gain remote access this way to my system and this samba thing allows it?

I might add that I was also only on this chat for about no longer than 1 - 2 minutes.

Thus I have also performed a multitude of scans and everything has come back clean.

I'd be very grateful for any info on this. thanks.

Samba usually refers to the *nix implementation of the SMB protocol.

Basically, it means you have a machine that is either directly connected to the net or has it's IP forwarded in your firewall and that has file or printers sharing enabled.

Whether that service can be remotely exploited (in any way) depends a lot on what's your actual setup it. However, finding an open SMB server usually is a sign of poor security since it's not a protocol that is commonly shared across public network.


Can a HTTPS MITM decypher server response packets? I am trying to fill in gaps of my understanding of HTTPS.

I understand that the server sends the client a public key to encrypt information and that only the server has the private key which prevents interception of request packets.

What happens in the response side of things? E.g. web application server responds with a session token, or is responding with sensitive information. Could a MITM attacker catch the initial public key response from the server and pretend to be the intended client? Or does the client also have a private/public key that it uses to handle the responses, and passes the public key inside the request?

Basically wondering if you can pretend to be the client, instead of most MITM where the attacker pretends to be the server.

There are two separate problems mentioned in this question: authentication and session encryption.

As for eavesdropping on the initial response, it is a problem of encrypting the session. Each session between the client and the server is protected using a different key. The key exchange algorithm (whichever is used) ensures only one party receives the keys used to secure the transmission.

The technical details were already explained in answers to How does SSL/TLS work?, but in brief an ephemeral key-pairs are used. They are separate from the public key sent by the server in the certificate.

The server's public key (included in the certificate) is on the other hand used for authentication (in public-key cryptography when you encrypt the data with a private key you are effectively signing it not encrypting, anyone can decrypt it with the publicly-known public key).

For the client authentication you can also use a key-based authentication, but this scenario is much less common. Usually you authenticate using password or some other method over an already-established secure channel. In this scenario there is no need or way to "pretend you are the intended client" because at the moment of initiating the connection there is no notion of the intended client yet.


Can I trust the source IP of an HTTP request? As far as I've understood, if you try to issue a HTTP request  with a spoofed IP address, then the TCP handshake fails, so it's not possible to complete the HTTP request, because the SYN/ACK from the server doesn't reach the evil client ...

...in most cases. But let's now mostly disregard these four cases:
- Man in the middle (MITM) attacks
- The case when the evil client controls the network of the Web server
- The case when the evil client fakes another IP on its own local network
- BGP attacks

Then I can indeed trust the IP address of a HTTP request?

Background: I'm thinking about building a map of IP addresses and resource usage, and block IP addresses that consume too much resources. But I'm wondering if there is, for example, some way to fake an infinit number of IP addresses (by issuing successful HTTP requests with faked IPs), so that the Web server's resource-usage-by-IP-buffers grows huge and causes out-of-memory errors.

(Hmm, perhaps an evil Internet router could fake very many requests. But they aren't evil are they.  (This would be a MITM attack? That's why I said mostly disregard, above))

Yes (with your assumptions of neglecting the client being able to intercept the return of the handshake at a spoofed IP) if you do things correctly.  HTTP requests are done over TCP; until the handshake is completed the web server doesn't start processing the HTTP request.  Granted a random user could attempt to spoof the end of a handshake; but as they have to guess the server generated ACK, they should only have a 1 in 2^32 (~4 billion) chance of doing it successfully each time.

As Ladadadada commented make sure you aren't picking up the wrong value of the remote IP address in your web application.  You want the IP address from the IP datagram header (specifically, the source IP address).  You do not want values like X-Forwarded-For / X-Real-IP that can be trivially forged as they are set in the HTTP header.  Definitely test by trying to spoof some IP addresses; with say a browser plugin or manually with telnet yourserver.com 80.

The purpose of these fields is so web proxies (that may say cache content to serve it faster) can communicate to webservers the user's real IP address rather than the proxies IP address (which may be for hundreds of users).  However, since anyone can set this field it should not be trusted.


Why for some SSL websites browsers show extra info, while for others dont While visiting some https websites (like online banks, etc) url string appear to have little extra green box on the left hand side, with some organisation details.

While other https websites just show a padlock

see example pic.

Why is that, and whats the difference.

The basic distinction is between a certificate verifying control of a domain, and a certificate verifying the real-world entity behind the domain. With a standard SSL certificate, all that's verified is that the entity with the certificate legitimately controls that domain. It doesn't mean that that's the entity I think it is; I could register bankofamerica.co, and I can then legitimately get a domain-validated certificate for it, and that would show up as a green lock in browsers.

What that box indicates is that CAs have done more validation; EV certificates (the green box) generally require actually verifying the existence and name of the business requesting them. I could not get an EV certificate for that site that says "Bank of America" on it, because I don't have a company called Bank of America, and even if I did the actual person reviewing an EV cert application (unlike normal certs, EV certs aren't automated) would likely be somewhat suspicious at someone claiming to be a bank.

So that's the stated role of EV certs: Verifying that the server sending you a webpage is the correct server for that domain doesn't really help unless you also know that the domain is owned by the company you want to interact with. With Google and Facebook, you know already that their websites are google.com and facebook.com, so I know that I want to talk to google.com, and if I'm talking to the real google.com that's enough. With other organizations, it's not necessarily enough to know I'm talking to the real so-and-so.com; I also need to know so-and-so.com is the actual website I want to be talking to.


Risk of giving untrusted IOT Device access to wifi My issue isn't so common and I can't find an answer in the see of other IoT security issues. Let's say I have an IP cam, but I'm not even worried about someone being able to view the live stream, or the live stream being 'stolen' and used in whatever way. I guess I'm only left with the question of: What are the risks of giving an IoT device my wifi password and connecting it to the wifi? I haven't found a clear answer. Thanks

This is a broad question and will take a broad answer.

Brutally, what is an IoT device?
It has (at least) a processor, a firmware and a nic.

All of that together can be compared, more or less, to a computer; usually with *nix software onboard.

From here, you can go for whatever you like, but to better understand the risks, you have to ask yourself, "What can a computer do when it is connected to my network?"

Let's pretend that your IP cam has a second wireless card that can be set in monitor mode.
It can be used to sniff all the traffic, because it already has your AP password.

You can't find a clear answer because theoretically there is not limit.

Being paranoid, not only you have to be worried about your live stream being exposed, but you also have to be worried about every piece of information in the other devices connected on the same network.

A simple misconfiguration of whatever device can be dangerous (E.G. ssh without password or a weak one, not patched machines, etc.)

Obviously, there are a lot of things that are very unlikely to happen, but backdoor'd software isn't that hard to find, specially in closed-source software.


Efficient and simple way of securing home pc with hardware token I am looking for a simple but reasonably safe way to secure my home pc (and laptop, nas, etc.) with a hardware token. I would like the system to be secure, but practical enough to be used on a day to day basis.

I am thinking of using the hardware token for logging on etc. (i know using just a hardware token is not that secure, but the system doesn't have to be ultra secure, just an initial deterrent). For ease of use i would like this hardware token to be as cross-compatible as possible (so i don't have to carry several of them).

I am thinking of using a usb token, because almost all computer hardware has a usb port nowadays. Even better would be a smartcard (because it would easily fit in my wallet), but smartcard readers aren't readily available (as far as i know).

The systems i'm thinking of using (and want to secure) are:

A password manager (keepass)
OS, disk and file encryption (truecrypt)
A nas with encryption (freenas 8)

My questions is: what is the easiest way to secure a system like this with a hardware token? What type of token would be best (in terms of portability, compatibility, etc.)? Or are there other ways in which i could accomplish the same, but easier?

EDIT: I was mistaken; Truecrypt cannot natively use USB device drivers for pre-boot authentication.  However, Yubikey appears to have a solution that can be used for their pre-boot authentication system as long as it is set up for "static mode".  This is interesting since it means that there is -- technically -- a way to allow USB-based authentication.  The Truecrypt docs are not clear at all that they do not support FDE with USB-based keyfiles.

Considering you've already looked at using Truecrypt, then ensure that full HD encryption is enabled and simply drop a keyfile onto your USB device.  USB is ubiquitous and the same device can be used to host multiple keyfiles for different systems.  Remember to make backups to prevent bit-rot and device failure.  This previous question has some thoughts on this (and more).