When did development on various TLS versions begin? What I'm looking for

I'm looking for an approximation of the date that the development on each TLS or SSL version started (so the development start date). So I do not want to know the date when the first RFC was released, but when people started working on the RFC (this could be something like the first draft, or some post on an email list). The date may be as accurate as a year or a quarter of a year, it does not have to be very specific.

 Why?

I'm making a timescale to illustrate the history of TLS and SSL versions. As the newest TLS version (TLS 1.3) is still in development, I would like to display this version as 'in development'. To make my timescale more consistent, I want to add the in development part to the other versions as well. As the timescale is mostly an illustration, an approximation or
anecdotal reference is enough.

What do I know

I do know the following data:

SSLv1 probably started in 1993 (https://books.google.nl/books?id=dR2G0oPufe0C&lpg=PA69&ots=UnIlNi_km1&dq=netscape+SSL+1.0&pg=PA69&hl=nl#v=onepage&q=netscape%20SSL%201.0&f=false "Netscape started to develop the SSL protocol soon after NCSA released mosaic 1.0 in 1993") done in the middle 1994; never released.
SSLv2 somewhere between 1993 and 1994? released end of 1994.
SSLv3 ??; released November of 1996
TLSv1.0 ??; released January of 1999
TLSv1.1 ??; released February of 2006
TLSv1.2 ??; released August of 2008
TLSv1.3 april 2014: https://github.com/tlswg/tls13-spec/commit/59a5a235cb90c1e380b025ee44931da13b2d5cbc ; not yet done

I have looked at the following sources:

http://www.metzdowd.com/pipermail/cryptography/2013-October/018041.html
RFC 6176
RFC 7568
RFC 2246
RFC 4246
RFC 5246
draft-ietf-tls-tls13
https://books.google.nl/books?id=dR2G0oPufe0C&lpg=PA69&ots=UnIlNi_km1&dq=netscape+SSL+1.0&pg=PA69&hl=nl#v=onepage&q=netscape%20SSL%201.0&f=false

Does somebody know more information about the history of these protocols?

Tldr
This is what the little research I did was able to find. Most of these dates are as you can read in the longer version, based on the first submitted draft of the respective protocols and not the first time they've been talked about. I hope this might help in your work anyway, and that it might help when doing further research.

SSLv1 - November/December 1993.
SSLv2 - At the end of year 1994, before November 29.
SSLv3 - 5. December 1995.
TLS1.0 - 26. November May 1996.
TLS1.1 - 19. February 2002.
TLS1.2 - February 2006.
TLS1.3 - 17. April 2014.

This is by no means a complete and "100%" list, and I hope someone wants to take the little research I've done and further expand on it.
The longer, more historical version
AS StackzOfZtuff also noted, the IETF Datatracker is a valuable tool for digging backwards in the history of RFCs, and will be a nice companion for the rest of your digging.
Netscape
SSLv1

Netscape Communications started to develop the SSL protocol soon after the National Center for Supercomputing Applications (NCSA) released Mosaic 1.0 - the first popular Web browser - in 1993. Eight months later, in the middle of 1994, Netscape Communications already completed the design for SSL version 1 (SSL 1.0)
SSL and TLS: Theory and Practice by Rolf Oppliger

Version 1 of Mosaic was released for the Windows platform November 11, 1993. (In the beginning there was NCSA Mosaic....). We could then guess that SSLv1 was done around July 1995.
Version 1 was never released publicly. Rolf Oppliger tells the tale why in SSL and TLS: Theory and Practice:

[SSL v1] circulated only internally (i.e., inside Netscape Communications), since it had several shortcomings and flaws. For example, it didn't provide data integrity protection. In combination with the use of the stream cipher RC4 for data encryption, this allowed an adversary to make predictable changes to the plaintext message. Also, SSL 1.0 did not use sequence numbers, so it was vulnerable to replay attacks. Later on, the designers of SSL 1.0 added sequence numbers and checksums, but still used an overly simple cyclic redundancy check (CRC) instead of a cryptographically strong hash function that is one-way and collision-resistant.

SSLv2 (Also known as SSL 0.2)
Netscape Communications came up with SSL Version 2. (SSL 2.0) at the end of 1994, to resolve the problems mentioned with SSL 1. SSL and TLS: Theory and Practice by Rolf Oppliger
tools.ietf.org/html/draft-hickman-netscape-ssl-00.txt
There is a mirror of the SSL 2.0 draft located in Mozilla's archives, but there is no date when the draft was orignally started or submitted, only when it was revised.
The spec got revised a couple of times:

November 29, 1994
December 22, 1994
January 17, 1995
January 24, 1995
February 9, 1995

Funfact:

Both SSL2 and SSL3 have 16-bit (two-byte) version number fields. SSL2 interprets this as a single 16-bit integer, and the official number is 2, e.g. 0x0002. SSL3 interprets two-byte version numbers as a one byte "major" number and a one byte "minor" (or fractional) number. So the value 0x0002 is interpret by SSL3 as version 0.2, not 2.0. http://www-archive.mozilla.org/projects/security/pki/nss/ssl/

SSLv3
SSLv3 was according to this draft first submitted to IETF 5. December 1995. draft-freier-ssl-version3-00.
IETF
TLS 1.0
The first TLS 1.0 draft was written in November 26, 1996 according to draft-ietf-tls-protocol-00.txt.
[edit 14:22 5/7/2015] As commented by @user23127, development of TLS 1.0 was started in May of 1996. "SSL and TLS: Designing and Building Secure Systems" by Rescorla, Eric, page 49, section 2.6
TLS 1.1
The earliest document I can find for TLS 1.1 is the [draft-ietf-tls-rfc2246-bis-00](https://tools.ietf.org/id/draft-ietf-tls-rfc2246-bis-00.txt
https://datatracker.ietf.org/doc/rfc4346/history/). Uploaded to IETF 19. February 2002 . Note that the header of that documents says:

The TLS Protocol
Version 1.0

They first added version 1.1 to the draft in the second revision published 6. October 2002: draft-ietf-tls-rfc2246-bis-02
TLS 1.2
The draft draft-ietf-tls-rfc4346-bis-00 states February 2006.
TLS 1.3
The earliest draft on IETF is this one: draft-ietf-tls-tls13-00.txt uploaded 17 April 2014. This matches the first commit on the GitHub repo tls13-spec that you linked to.


HTTPS and Basic Auth I've set up an NGINX reverse proxy on my home server with dynamic DNS from my website 'stuff.mydomain.com' along with a certificate from letsencrypt. I'm using basic auth to authenticate users.

When I go to my domain and the authentication box pops up, chrome does not indicate that the connection is secure (I get the "Info or Not secure" 'i' symbol). If I log in or click cancel it immediately turns into the green lock symbol and stays that way.

Is this the way it is supposed to work, or did I mess up the setup and am transmitting login information unencrypted?

Edit: The same thing happens when I enter https:// for the URL. Any ideas?

Edit 2: After messing around with wireshark for a while, I'm pretty sure everything is actually encrypted (I checked both http and https in the URL bar). I still don't know what's causing chrome to show it as insecure.

A late response, but this is a long-standing bug in Chrome.  Chrome doesn't update the security indicator in the address bar before showing the basic auth dialog (though it does validate the security correctly, so an expired certificate is correctly marked).

https://bugs.chromium.org/p/chromium/issues/detail?id=700748
https://bugs.chromium.org/p/chromium/issues/detail?id=667021 (see also 395050)


TLS without Private Key Someone on my team said that there is a form of TLS that can be utilized that eliminates the need for a private key. They are "above" me, and I didn't want to argue without knowing for certain that is not the case. I've done my homework and the private key is critical for verification of the client/server identity. This is what I thought. Yes, there are ways to script the re-creation of these keys upon every session, but that's extreme.

Is there any way to have a private-keyless TLS that is not just some hacked together "symmetric encryption"?

TL;DR: TLS can in theory be used without private keys.

An integral part of TLS is that the client properly authenticates the server in order to detect potential man in the middle attacks. This is commonly done with certificates - and this requires the private key of the certificate on the server site to prove to the client that the server is the owner of the certificate1.

But, TLS is flexible and also provides other ways to authenticate the server. There are PSK ciphers which allow authentication by using a pre-shared key between client and server. There are SRP ciphers which allow authentication by password. There are even anon ciphers which allow you to abandon any kind of in-TLS authentication, i.e. require you to do your own authentication.

Thus, TLS might be used without certificates. And since certificates are the only part of TLS which requires a private key this means that TLS can be used without private keys. But, even if no private key is used a similar secret thing might be required on the server: both SRP and PSK based authentication require a secret on the server side which should at most be known to server and client.

Apart from this, certificate-less (and thus private-key-less) authentication requires both sides of the connection to support the relevant ciphers with the alternative authentication methods. Since browsers currently only support certificate-based authentication a private key is needed on the server side whenever access by a browser is required - i.e. practically every time in case of web servers.

For example you can use openssl to provide a TLS protected connection which does not require certificates. The server would look for example like this:

$ openssl s_server -www -nocert -psk 1a2b3c4d

The client would need to use the same key when connecting to the server, i.e. the basic idea behind PSK is that client and server share a secret key:

$ openssl s_client -connect 127.0.0.1:4433 -psk 1a2b3c4d
...
Cipher    : PSK-AES256-CBC-SHA
...
Verify return code: 0 (ok)

If you would try to connect with a browser to this server (i.e. https://127.0.0.1:4433) you would only get an error since the browser does not support the PSK ciphers: ERR_SSL_VERSION_OR_CIPHER_MISMATCH.

1 Private keys can not only be required for authentication but also for key exchange, i.e. RSA key exchange. But, RSA key exchange requires certificates so it again means that private keys are only relevant if certificates are used. Also, the Diffie-Hellman key exchange does not need certificates and this is actually the recommended method today since it provides forward secrecy.


DoD 52220.22-M (3 Pass wipe) and Virtual Machines So my place of work, if you can tell by the title is either Gov or Mil, and we recently had a tech refresh where all of our workstations were replaced with VM's. We are running version VMWare Version 14 on ESXi version 6.7. VM's are Windows 10.

A question was posed today that, if an Information Assurance (IA) violation happened on one of the VM work stations, how would you effectively wipe the data? Because with a phyisical machine, you do a 3 Pass wipe on the HDD and then re-image it. But how, if the ESXi hosts share the data stores for the VM's, do you effectively remove that VM's HDD presence without doing a 3 pass wipe on the entire ESXi host?

Any info or other DoD publications you know of, would be greatly benefitial. And before you suggest any third party software or different versions, please know that it is not possible for us to install any tools or versions that have not been tested and approved by both the DoD and by our PMO(Project Management Office).

This answer won’t make you happy because it won’t match government check box security.

First of all, the 3 Pass Wipe derives from a decades obsolete MFM disk technology that no one uses. It makes no sense on modern disk drives. Yes I know – government rules.

The same type of issue occurs with an e-mail “spill”. No one is going to wipe the main email server drive due to an individual “spill”. Instead the affected accounts will be manually sanitized and sometimes if the spill is bad enough, a free-space wipe on the server will be performed.

Similarly to the email server, depending upon the severity of the issue:

The VM disk file can be manually cleaned and compressed
The VM disk file can be wiped
The ESXi hard drive can have free-space wiped after VM deletion/wiping.

3 Pass Wiping of a VM is just security theater, but it may check bureaucratic boxes.

None of this meets Old School remediation standards, but times change and even the government has to change.

Throw in the likely possibility that the VM virtual disks may actually reside on a virtual LUN from a RAID array of physical drives in a SAN and Old School goes right out the window.


How do I prove my proxy is scanning for viruses? I have a proxy server in my DMZ that among other tasks has the role of scanning incoming messages - email, SOAP - for viruses. How do I prove to my team leader that it is performing this role on all incoming messages?

You can't really prove it, without going through proxy lo gs, antivirus logs etc., but you can certainly get confidence that it is by sending some test messages through with the EICAR signatures in it (see http://www.eicar.org/anti_virus_test_file.htm).

You can then see whether it flags them.


Why are there very expensive and cheap SSL same type certificates? I am about to launch an online shopping site (currently running http) and I was thinking heavily of moving to SSL which includes a green bar, because this is very important.

However, when I first checked it out, I found it was very expensive at first. But then I found a unbelievable price, for which I can't find the reason behind it.

Verisign (now called Symantec) offers the SSL I want (Symantec Secure Site Pro with EV SSL Certificates) for $1499 per year, which I find quite expensive.

But

I saw that the same thing could be obtained from Comodo (EV SSL - Extended Validation SSL Certificates) for just $99 per year.

There is a really large difference between these two prices, and I don't understand why. I am really attracted to the Comodo certificate, because it's very inexpensive, but I am not sure, because my mind says there has got to be a CATCH here.

What is the actual difference? Is there a big catch? OR is it just branding? (I really don't think it is, because of the huge gap in price)

SSL certificate price depends basically on how much the vendor feels he can charge for it. The per-certificate issuing cost is extremely small; most of it is about the manual operations to verify the identity of the requester, but that is still a lot less than what CA typically charge. Like with software, CA charge money to cover their development cost, and/or to get filthy rich.

There can be some sub-clauses about insurances. When you buy an EV certificate, you also pay for some insurance that will cover some cases of fraud related to certificates. You have to read all the fine print of the insurance contract to know exactly what you are buying. It is plausible that a 2000$ certificate comes with a more comprehensive insurance policy than a 99$ certificate.

It is also entirely possible that some CA think that by making their prices 10 times higher, they will have less customers, but not 10 times less customers, thus making the operation worthwhile. Customers are people; they tend to think about certificates as some magic things, and are not very rational about them.


Security of hybrid encryption scheme I want to use a hybrid encryption scheme for file encryption.
The scheme must use PKCS#1 v1.5 – which is vulerable to padding oracle attacks – because many smartcards (e.g. the OpenPGP Card) only support PKCS#1 v1.5.

So I came up with the following scheme (the RSA-keys are 4096-bit large, the symmetric algorithm is either AES-256-CTR or ChaCha-20 with 256bit keys and of course different keys for signing and encrypting are used. And of course I know that for stream-ciphers absolutely unique IVs must be used with the same key):

Encryption:

var privateSigningKey;
var publicEncryptionKey;

---   var encryptedBlock = encryptAsym(sessionKey, iV) + encryptSym(data + hash(data));
+++   var encryptedBlock = encryptAsym(sessionKey, iV) + encryptSym(data + sign(data));
var signatureBlock = sign(encryptedBlock);
var encryptedData = encryptedBlock + signatureBlock;

return encryptedData;

Decryption:

var trustedPublicKeys[];
var signatureBlock = encryptedData.getSignatureBlock();
var encryptedBlock = encryptedData.getEncryptedBlock();
var sender = "";

for each trustedPublicKey do {
    bool signatureValid = verifySignature(encryptedBlock, signatureBlock, trustedPublicKeys[i].getSigningKey();
    if (signatureValid) sender = trustedPublicKeys[i].getName();
}

if (sender == "") exit("Untrusted signature; stopping to prevent padding oracle attacks.");

var plainDataBlock = decryptHybrid(encryptedBlock);
---   var hash = plainDataBlock.getHash();
+++   var signature = plainDataBlock.getHash();
var plainData = plainDataBlock.getPlainData();

---   if (hash != hash(plainData)) exit("Decryption failed.");
+++   if (signature != sign(plainData)) exit("Decryption failed; untrusted signature.");

return plainData;

Can this scheme considered to be secure? Or are there any security issues or better alternatives?

I know that you usually don't roll your own crypto; but I cannot use the OpenPGP format because it doesn't prevent padding attacks (look at this question) and I don't know any better alternative.

Edit: Scheme updated

Your scheme does not protect against an adversary choosing the same SigningKey as an honest party.  Even if that is not a problem, whether or not an adversary could falsely "get credit for"

a plaintext still depends on the details of PKCS#1 v1.5, since it would need to be infeasible

for an adversary to find a different malicious SigningKey for which is likely to accept a

mauled version of a message-signature pair from the honest sender's privateSigningKey.

Similarly, your scheme does not protect against an adversary choosing the same

publicEncryptionKey as an honest party.  Even if those were not a problem, whether or not

your scheme provides authenticity would still depend on the details of PKCS#1 v1.5,

since it would need to be infeasible for an adversary to win the following game:

adversary receives an honestly-generated SigningKey and publicEncryptionKey

adversary outputs a plaintext data an alleged RSA public encryption key maliciousEncryptKey

sessionKey and iV are generated honestly

using maliciousEncryptKey,

encryptedBlock = encryptAsym(sessionKey, iV) + encryptSym(data + sign(data))

adversary wins if and only if plainDataBlock = data + sign(data)

I'm not aware of any "approved" alternatives. However, the majority of a good alternative is:

have encryptSym be some implementation of one-time authenticated encryption

let bracketed lists denote some way to unambiguously indicate all entries of the list

(If all but one of them have known length, then concatenation would work,

otherwise one could use something like prefixfree(x) || prefixfree(y) || z .)

let to_be_signed = [receiver's_name,receiver's_public_keys,data]

let encryptedBlock =

[encryptAsym(receiver's_public_encryption_key,sessionKey),
encryptSym([sender's_name,sender's_public_keys,to_be_signed,sign(to_be_signed)]

omit signatureBlock, and just return encryptedBlock

If there's no need for encryptedBlock to hide sender's_name, then that and

sender's_public_keys can be made associated data instead of being encrypted.

If one is confident in the CCA-security of the public key encryption, then the part of this answer

before this sentence but after the horizontal line will almost work.  (See this answer's last paragraph.)

Otherwise, one should choose distinct equal-length values a and b (the bits 0 and 1

in either order would work fine, but it might be more convenient to let them be whole bytes),

replace to_be_signed with a || [receiver's_name,receiver's_public_keys,data],

and let signatureBlock  =  sign ( b || encryptedBlock )  instead of omitting it.

Note that in this case, signatureBlock will usually be enough to deduce sender's_name,

which means there is usually very little point in having encryptedBlock hide that.

One also needs to make sure the bracketing operation and signature scheme are such that the lengths of their outputs do not leak anything more than necessary about information that should stay confidential

(since encryption can leak the length of the message).  As a sufficient condition, those will hold if

{lengths of list representations depend only on the lengths of the entries and for honestly generated signature key-pairs, lengths of signatures depend only on the lengths of the corresponding messages}.

Also, if you want to allow for multi-receiver messages, then things are significantly trickier than

what I've described in this answer (though for reasons unrelated to the rest of this paragraph).


How can I uniquely identify an user when cookies are not an option? In web application development, how can I uniquely identify an user when cookies are not an option and IPs are dynamic? Are the patterns which I can combine and then created a hash to be used as a UID?

Before cookies existed there was a form of authentication called "basic access authentication"  This form of authentication sends the username and password with each request.  It's still used in some primitive web applications.  Remember though that this doesn't provide any encryption of the password, so you MUST use https, otherwise an  attacker can trivially learn the password.


Can random subdomain naming enhance security? I have a bunch of services which I want to group under a subdomain. Somehow 2-factor authentication is not possible to identify the users of these services. I have a thought to have randomly named subdomain to make it difficult for the attackers to know my subdomain. So, let's say I have a domain example.com and I want to group service1, service2, service3 under the same randomly named subdomain, then my urls would look like:

https://q45vzle.example.com/service1
https://q45vzle.example.com/service2
https://q45vzle.example.com/service3

The q45vzle is the randomly named subdomain. Does having such a subdomain name really help in preventing it from getting discovered? If yes, then how strong the random subdomain name needs to be? If no, what could be the security method which I can use for this situation?

Feel free to correct me if I am having a whole series of wrong thoughts.

You should assume that an attacker can observe traffic. This may happen at your network endpoint, at the client's end, or somewhere in between.

On the client side, the attacker will see DNS resolution for random.example.com if he is observing your users, and he may also discover this domain name if he attempts to access to site directly (this second method depends on how tightly you control references/redirects on the main site to the subdomain).

Plus, if you are using certificates for TLS (as you should be), you will have a certificate listing random.example.com, either as the named entity or an alternative name. That will be visible on the wire.

An attacker may be able to browse the DNS zone records in a more direct fashion. As a general rule, you should assume that everything you publish to DNS is available to everyone. If a legitimate client can find the record for that subdomain, so can nefarious users. If you try to hide the subdomain name behind a wildcard record, then the attacker will know the destination IP address regardless.

In the absence of two-factor authentication, a strong password authentication implementation is your primary security. This implies both reasonably complex passwords and a modern hashing algorithm such as scrypt or Argon2. Additional measures would depend on the application and the users. If you can restrict access via firewall, that would be a good step; however, this is only feasible if users can register devices quickly or in advance.

Your question isn't clear if only hardware-based 2FA is excluded. Don't forget about the second-class 2FA options, if permissible. They are better than nothing. If you can transmit a secret to the users out of band via email/text/phone, it is a worthwhile effort.

Alternatively, you could provide a passcode during registration/enrollment, and your site will accept that code to issue a permanent cookie; that cookie can then act as the second factor.

Unfortunately, these methods can be compromised, unlike a hardware 2FA device. Realistically, most sites use nothing more than TLS and a strong password requirement, and they are fine.


ModSecurity Block based on ARGS_NAMES starting character Working on a rule to block traffic based on the starting character of ARGS_NAMES either cookie, get or post

Example allow

name=Joe

Example block

#name=Joe

Test rule that is not working

SecRule ARGS_NAMES "^(#.*)$" "phase:1,id:199,log,deny,msg:'Block Argname with hash'"

These rules seems to work  on 2.8

SecRule ARGS_GET_NAMES "^(#.*)$" "id:193,log,deny,msg:'Block ARGS Name with hash GET'"

SecRule ARGS_POST_NAMES "^(#.*)$" "id:192,log,deny,msg:'Block ARGS Name with hash POST',logdata:'%{tx.httpbl_msg}',setvar:tx.httpbl_msg=$"

SecRule REQUEST_COOKIES_NAMES "^(#.*)$" "id:194,log,deny,msg:'Block ARGS Name with hash COOKIE'"

But better solution https://twitter.com/CoreRuleSet

SecRule ARGS_NAMES|REQUEST_COOKIES_NAMES "@beginswith #" "id:123,phase:2,block,msg:'SA-CORE-2018-002'"


Can risk mitigation controls bring down the impact? While doing a Risk Assessment, I found that in some old RA documents, after controls have been placed, the Impact in the forcasted value was changed that did not make sense to me. To me the impact never changes as the impact of a critical service being down is the same whether a control is in place or not. What changes however is the probability bring the Risk down (Risk = Probability x Impact). Is this correct?

The impact may change if the control put in place alters a potential attacker's abilities should the problem be exploited.

A good example of where the impact would change is when the mitigation involves segregating networks. Before the segregation, an exploit on OldCorp Unsupported Legacy Daemon X might lead to someone getting access to the internal network, then exfiltrating all your yummy internal documents out of SMB shares. After segregation, the box on which OldCorp ULDX sits is no longer in a position to route packets to your "regular" corp network, so the impact of it getting owned is reduced.


Hardware-backed Keychain for iOS and Android I'm researching on hardware-backed keychain for iOS and Android, in order to store some certificates in hardware rather than software. According to Android docs (https://source.android.com/security/keystore) Android versions 4.3 and above support hardware-backed keychain, but with limitations on devices. I'm assuming it requires some sort of SoC with ARM Trustzone (or the equivalent intel x86 counterpart). Is there a list of such devices and/or SoCs?

In the iOS world, Apple seems to offer secure enclave technology (http://spr.com/ios-security-protecting-the-ios-keychain) which is a co-processor. Can keys and certs be stored in this secure enclave by app developers?

Thanks.

No the enclave is just for the iOS encryption processes.

  It turns out this was the perfect convergence for the synergy needed
  to allow Apple to move forward with TouchID. Apple has customized a
  highly optimized version of TrustZone and created what is now known
  Secure Enclave.  Of course Apple will likely never release the details
  of what they do in the custom hardware for number of reasons. Thus I
  will speak directly of TrustZone and extrapolate to Secure Enclave.

  ...snip...

  Apple has wisely restricted very, very limited access to Touch ID and
  does not have any APIs available for developers.  In fact Apple has
  removed the iCloud Keychain from the most recent developer build of
  iOS 7.  I can only publicly say this has a lot of reasons that will be
  very clear in the next few months.  The technology is now limited to
  just two use cases, device unlock and iTunes and App Store purchases.
  Of course this was not the limited intent of this technology and there
  will be full developer API access at some point, perhaps not in some
  areas that Apple will limit as they want to be the sole provider in
  those areas.

  Source

More information about it can be found here:iOS and here:Android.


Speed up Reaver attack on router I am trying to get the WPS pin by Reaver attack.

The code I run is

reaver -b (bssid) -c (channel) -i wlan0mon -vv

It takes too much time guessing the WPS pin because it starts counting from 0000****.

The router I am trying to hack is TP-Link and I also know that the WPS pin starts with 7. Can I speed up my attack by commanding Reaver to start testing the numbers that start with 7?

Is there anything else I can do to speed up my attempt?

When you run Reaver it creates a session file in the current folder to allow you to resume in case the execution gets interrupted. You can run reaver to create the session file, stop it then edit the session file. The very first line contains the pin it was at when stopped.

Change that to the PIN value you want to start at (like 70000000). Then run reaver again with your parameters. It will ask you if you want to resume the session. Say yes and proceed.

Alternatively you can add -s <session file> to your parameters and it will resume the session automatically.


Securing a video using encryption Videos uploaded on Youtube or any other video streaming website can be easily downloaded by using 3rd party software.

In order to prevent the viewers from sharing the video to unauthorised people. I thought of this solution.

Encrypt the video file using bash.
Send the folder using any file sharing service.
The user will run the bash file in order to decrypt the video.
The bash script will fetch the key from my server.
Then it will decrypt the video file and run it.
When the file will close, the bash script will encrypt it again.
The key on my server will expire on a specific date.

The users are not very tech savvy to understand what is going on behind the scenes. But this will protect my videos from piracy.

Is there any better solution for what I want to achieve? As this is not a cross platform solution.

EDIT : I am fully aware that it is very simple for a user to read the bash script and fetch the key. I am just trying to create an illusion that the video cannot be copied.

When something goes public (let say EME as Daniel Ruf mentioned), first it gets some specification and protocol.

The next part is the implementation, now people and companies grab the protocol and implement it.

Even if you assume EME uses a strong cipher(let say AES_256_GCM), it's simply insecure just like it's not secure. Because as you would read the specification, you would implement your own code.

At the end all of these encrypted stream/descriptor must be in plain form where the client can display, at this phase you would simply write down the plain stream/video with a common format(h265/HEVC for instance) in a file.

This situation is special for the video and audio. Or generally most rich media(not all of them)

If it was really possible, hollywood could do it of course no doubt, but it's not very logical and possible yet with the way we stream video.

daniel also mentioned more logical and reliable solution. Yes you need to just ask people nicely to respect the copyright.

Not just video, even for many other stuffs that you could get some level with 1 year of research and coding, you would keep working on the system to keep it update and updated with people's needs instead.


Router vs router + switch security I need to add some more ethernet devices to my network. I'd like to keep the current router and the only possibility to add more interfaces would be USB ethernet / PCI ethernet adapters. I could also use a network switch instead and connect it to one of the current router ports and easily get a lot of new interfaces.

But I was wondering if one setup would be less secure than the other one. It breaks down to the configuration I guess. The router does normal NAT'ing and each port currently provides a different network.
My goal is to isolate the different connected devices so they can't communicate with each other.
A dumb switch wouldn't do any good while managed switches provide some isolation as far as I know but I don't know if it comes close to the one provided by a router. If I go for the router and switch setup is there also anything I need to change on the router side?

A managed switch configured to use VLANs is the proper way to do this. In principle the security you get from the isolation implemented on the router and the isolation implemented by a managed switch is the same.

Of course security vulnerabilities can exist in the products you choose to use. So in practice there can be differences in security between the two approaches. But those differences will be due to security bugs and not inherent issues associated with either approach.

There is a good chance the isolation implemented by the router is in fact done by a VLAN capable switch chip in the router. This answer has a nice diagram of what the internals of typical consumer routers look like.

Some managed switches have a VLAN mode specifically intended for the usage case you describe. See for example this question about VLAN on TP-Link switches.

But even if the switch doesn't have this feature you can expect every decent managed switch to support tagged VLANs which can be configured to achieve the same effect. One potential obstacle to look out for is whether your router supports the configuration of VLANs to achieve the desired isolation. That is something you can verify before purchasing a managed switch.


Getting access to MAC address of access point from a device wired to the network My home network consists of a router (with wired and wireless connections), and a separate access point used to repeat the router wireless signal.
A device is further wired to the access point; it does not have a wireless interface.

Is it possible for the device to determine the MAC address/SSID of the access point, of the router, or of any other wireless network in range?

My concern, and the thing that I want to avoid, is that the device could determine the MAC addresses of wireless networks either attached to my network or in range, thereby using Google Location Services to determine my physical location.

If the device is "evil" then it may contain a WiFi receptor and observe the message in the radio vicinity. It will then obtain all MAC addresses and SSID that it may wish for.

If the device is not evil to that point, but is only a casual, amateur evil, then it may still see the MAC addresses of devices that do WiFi with the "repeater". If the repeater behaves like most other repeaters, then it is a router (at the IP level) and the evil device will see frames (hence MAC addresses) only for the clients who connect to the repeater, not to clients who connect to the main access point. Moreover, WiFi-related features (e.g. SSID) will not be shown to the evil device, since it is wired. It is possible that the MAC address of the repeater itself, on the wire, will be identical to the MAC address used by the same repeater on the WiFi layer (some devices use per-interface MAC addresses, other use per-device MAC addresses).

Since all of this relies on some assumptions about the repeater, I suggest that you try it: instead of the evil device, plug a laptop computer and run a network monitor tool (e.g. Wireshark) to see exactly what frames show up on the wire.


How to protect file integrity and history containing counters I would like to create a solution that would sign the data and will have a increasing counter so I can track the number of signatures.

One of the requirement is to have an increasing order of signature to track the history. As I would like to store counters on external file I need to protect the file also for change of the history.

For example I will store increased counters in file, let's be it number 15. Then I will do another signature and store updated file with the number 16. I would like to protect the solution from replacing file with the previous version of the file containing counter 15, so it wouldn't be possible to go back in the past.

I am aware of cryptographic techniques to protect the integrity of the file but I do not know how to ensure that it wouldn't be possible to replace the file with the previous version.

Any advice?

You need a Consensus Protocol for that. Keep the file saved on 3 (or 5, or more) distinct servers, and every time the file is modified, send the new version for those servers.

The servers, in turn, verify if the file is a new version with the incremented counter, and if so, they can store the hash of the file on the ledger after the majority of the servers agree the file is a new one.

To verify any file, you submit your file to the server, the server verifies if he have the same version, and tells you if your version is an older version, the current version, or a version never seen before.

This way, an attacker would have to compromise the majority of the servers to revert any file to a previous version.

Or you can use existing solutions for that. There are current solutions for storing data on the blockchain. There are Ethereum smart contracts for that: you can store the counter and the hash of the document, and keep track of changes. If anyone tries to revert the counter, you can search on the Ethereum blockchain and detect it.


How does WifiKill work? How is possible for Wifi Kill to block someone from using Wi-Fi, even if you don't have access to the router settings and you even don't use MITM (I think)?

By using disassocate packets.

Those packets has the source MAC of an AP and force the client to disconnect and reconnect to the AP.

By keeping sending those packets, you can keep any client away and unable to connect to this specific access point.

Edit:  A summery for people can't access links.

From a tool named Aircrack-ng

Deauthentication
Description

This attack sends disassocate packets to one or more clients which are currently associated with a particular access point. Disassociating clients can be done for a number of reasons:

Recovering a hidden ESSID. This is an ESSID which is not being broadcast. Another term for this is “cloaked”.
Capturing WPA/WPA2 handshakes by forcing clients to reauthenticate.
Generate ARP requests (Windows clients sometimes flush their ARP cache when disconnected)

Of course, this attack is totally useless if there are no associated wireless client or on fake authentications.

  Note: Some clients ignore broadcast deauthentications. If this is the case, you will need to send a deauthentication directed at the particular client.

Source: http://www.aircrack-ng.org/doku.php?id=deauthentication


CCNP, OS, and Cyber Security I'm a student aspiring to pursue a career in the field of cyber security. I'm studying computer science but am very new to the actual industry world.

I've recently signed up for an academy that offers classes and told my mentor that I want to go into security. He told me to take courses regarding networks, operating systems (Linux, Windows, etc.), and then I could go into specific fields (e.g. reverse engineering, web hacking, etc.) He also told me it's highly recommended to get a CCNP certificate on the way if I can. He also added that it might take awhile to get the basics down before going into the actual stuff.

I was just wondering if it's imperative that a cyber security specialist have a deep and strong understanding of networks and OS?

In short, yes, it is very helpful if you have a deep comprehension of networks and operating systems to start with. You cannot secure what you do not understand. Your teacher is right about what they have told you.

Within information security, there are many specific careers you could have -- penetration tester (white hat hacker), security manager (more corporate), cryptography (more math-oriented), systems security (more system admin work), network security etc. Please see the domains of CISSP certification for example: http://library.ahima.org/doc?oid=107038#.WeBKrMiGPIU

I would recommend starting with the basics of networks, systems, and software first and then touching upon the various domains of information security. From there on, choose what you would like to specialiaze in within information security and focus on that.


How to detect whether my network's key is being attempted to be cracked? I use WPA2 encryption. But I know even that can be cracked with the aircrack suite. And a lot of users may not use strong passwords. I've read that while cracking WIFI keys the only noticeable difference is the rate of traffic. So is there a way to detect whether my network is under attack from such tools ?

P.S: A solution without the use of IDS will be appreciated. Also, are most IDS' able to detect these attacks ?

Yes, if they are trying to break into your network in a particularly obvious way, but no for the general method of attacking WPA2 with a weak pre-shared key.

If they are trying to brute force into your network by repeated attempted logins (e.g., exploit the flaws of WPS - Wifi "Protected" Setup ), you can listen in on the network traffic, you would see the large fraction of unsuccessful login attempts.  (Or even easier your wireless AP logs failed wifi login attempts).

This would require setting up wireshark on a computer that has a wifi card that can listen in promiscuous mode to the traffic.  I've heard that this cannot be done in windows (not a windows user so I am not sure of this), so you may have to use linux or a Mac.

Granted most attacks on WPA2 do not work like this (excluding those on WPS).  Most attacks work by observing someone else's successful WPA2 handshake (listening in promiscuous mode) to a given access point (knowing the BSSID).  Then locally run take that handshake through a password cracking program until they find a match.  This cracking is done entirely by eavesdropping and offline cracking, so would not be detectable.

However, these attacks are computationally expensive and will only work in practice against weak passwords or slightly stronger passwords with a common SSID (like NETGEAR / linksys / default / dlink / wireless / Home). This is because the actual password used is a combination of the SSID + preshared key. Rainbow tables (precomputed tables) are generated for common SSID's, and when used, increase the speed of recovering your password. It is advised to change your networks SSID to something unique.

If you have a passphrase that is high entropy (not likely to be in any dictionary attack) and a unique ssid, these offline attacks against your network will be unsuccessful.


Is it okay to wrap a cryptographic hash with MD5 for storage? Is there any security issues if you wrap your cryptographic hash with MD5 for storage purposes?

For example:

$hash = md5(hash($password,$salt,$rounds));

Note: hash() uses scrypt or bcrypt or pbkdf2 internally.

The only purpose of md5 is for storage since it only uses 32 bytes vs storing very long raw hash.

EDIT: Judging from the comments below I agree MD5 is not a good idea as it is collision prone but what if I use a better hashing function like SHA512? Still, comments below argue it may actually weaken it but can somebody please explain how?

How can this:
$hash = SHA512(bcrypt($password,$salt,$rounds));

be weaker than this:
$hash = bcrypt($password,$salt,$rounds); ?

It appears to me the former is stronger since you have to "crack" SHA512 first before you can even begin working on cracking bcrypt. Why others says otherwise?

You don't lose anything by applying MD5.

Since you use md5(hash()) as your combined hashing scheme, presumably the attacker doesn't have the ability to submit an input that is only evaluated by md5(); it's either evaluated by the whole scheme or nothing at all. So given a hash h in your database, the attacker's goal is to find m such that md5(hash(m)) = h. (m may or may not be the original password, since a collision password is good enough to allow them to log in fraudulently.)

Assuming the attacker obtained h and they were able to take advantage of a weakness in MD5 and find a pre-image h' such that MD5(h') = h, that doesn't help them since they then still have to find the pre-image of h' in hash. If hash is sufficiently strong in it's own right, this is no weaker than using hash by itself.

The gist of the idea here is that MD5 acts like a random map of inputs to outputs. MD5's mapping is well distributed and random strings don't generate collisions. Security-wise, MD5 makes it too easy to intelligently craft collisions, but we don't care about the the attacker intelligently crafting the input to MD5 in this case, we only care that by adding a mapping to the output of hash we don't create more collisions with MD5(hash()) than expected of hash by itself. In other words, you aren't relying on MD5's cryptographic collision-resistent properties here. You could add any sort of random-ish mapping to the output of a good hash function and, as long as that mapping isn't prone to accidental collisions, you should lose nothing.

Addressing the updated part of the OP: You can use SHA-512 and truncate the output. The recent FIPS-140-4 standard specifies truncating SHA-512 to a handful of lengths. This is a fully-endorsed method.


Force "Remote Host Identification Has Changed " warning I have a client-server pair and am trying to reproduce the warning:

  REMOTE HOST IDENTIFICATION HAS CHANGED!

I am aware that one way to achieve this is to change the ecdsa key on the ssh server and force the server to use its ecdsa key to identify itself by editing Hostkey in /etc/ssh/sshd_config.

What I am curious about is if it is possible to do the same by changing the server's ecdsa public key in the client's known_hosts file. So far, if I change the key and try to ssh to the server the client just asks me to verify the key:

  The authenticity of host '10.1.1.1' can't be established.

Does this mean that the server fingerprint or the public key is cached somewhere in the client?

The issue is likely that you are changing the host key in such a way as to make it unparsable. If you try using ssh -v [host] you'll probably see something like this:

debug1: /home/[user]/.ssh/known_hosts:1: parse error in hostkeys file

If you want to cause a verification error rather than a parse error that gets ignored, you'll have to change the key in a way that ssh still thinks it's valid. The way to do this depends on what type of key it is. You can force host key types with HostKeyAlgorithms (eg -o HostKeyAlgorithms=ssh-rsa). The most common host keys you'll run across with OpenSSH are RSA and ECDSA.

RSA

If you have an RSA host key, Thomas Pornin describes the public key format here:

00 00 00 07             The length in bytes of the next field
73 73 68 2d 72 73 61    The key type (ASCII encoding of "ssh-rsa")
00 00 00 03             The length in bytes of the public exponent
01 00 01                The public exponent (usually 65537, as here)
00 00 01 01             The length in bytes of the modulus (here, 257)
00 c3 a3...             The modulus

To avoid an invalid format error, you'll have to keep the string lengths and key type valid. OpenSSH also checks that the public exponent and modulus are not equal to 0, that the modulus is greater than 0, and that the modulus is at least 1024 bits. Here is an example key with a public exponent of 1 and a modulus of 21023 (note that this is not a valid RSA key, it just passes the checks OpenSSH uses for keys in known_hosts):

AAAAB3NzaC1yc2EAAAABAQAAAIEAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=

In general, you can change pretty much anything after the 33rd or so base64 character, as long as you keep it the same length and valid base64. All that's required is that the modulus is > 0 and at least 1024 bits.

ECDSA

You can find the key format in the RFC and SEC 1:

Let's break down this example key I just generated:

AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBNLpVyqsu97ajvCDAcc8/W50xhG/Rt2qOxdiy05hAJJtwRTPZRJxrCLayFDWWkNY5ZICRQoYB6Fn7z42JPZNUaI=

00000013                                  Length of string (19 bytes)
65636473612d736861322d6e69737470323536    ASCII encoding of "ecdsa-sha2-nistp256" ("ecdsa-sha2-[identifier]")
00000008                                  Length of string (8 bytes)
6e69737470323536                          ASCII encoding of "nistp256" ("[identifier]")
00000041                                  Length of string (65 bytes)
04d2e9572aacbbdeda8ef08301c73cfd...       Q

Decoding Q according to SEC 1 section 2.3.4:
04                                                                 W
d2e9572aacbbdeda8ef08301c73cfd6e74c611bf46ddaa3b1762cb4e6100926d   X
c114cf651271ac22dac850d65a4358e59202450a1807a167ef3e3624f64d51a2   Y

The OpenSSL functions OpenSSH calls for ECDSA keys actually verify that the point is on the curve, so you'd have to do some math to change it to another valid public key. At that point you might as well just generate a new one using:

ssh-keygen -t ecdsa -f /tmp/key -N ''
cat /tmp/key.pub
rm /tmp/key{,.pub}

You can of course do this for RSA and other keys as well.


How to get a green certificate bar if I'm not a company? I'm not a company and do not represent one, but I would like to have a green bar on my website for several reasons. One of them, for example, is that I want to ensure that the information displayed in the page is really from me, and any other reasons to ensure trust for anyone who's reading it. I know that these types of certificate are called Extended Validation Certificates. I googled how I could get one as a individual and I found this. It says here that I could get a OV. But it will not say if I'll get a green bar or so.

How can somebody, say, a journalist, get a green bar cerficate for its blog to ensure that its his real blog? How can a security analyst ensure that it's his website that people are visiting? How can someone ensure that a person is not visiting a URL thats similar to yours? How can I know that I'm not accessing for example googIe.com instead of google.com? (some URLs do really look alike when some letters are replaced by similar ones).

I can think of a lot of applications for this, in that they do not need to be a company but need to be trusted more than a simple automatically generated certificate.

Refer to the guidelines set up by the CA/Browser forum for extended validation.

  8.5.1 General

  The CA MAY only issue EV Certificates to Applicants that meet the
  Private Organization, Government Entity,Business Entity and
  Non-Commercial Entity requirements specified below.

  8.5.2 Private Organization Subjects An Applicant qualifies as a Private Organization if:

  (1) The entity’s legal existence is created or recognized by a by a
  filing with (or an act of) the Incorporating  or Registration Agency
  in its Jurisdiction of Incorporation or Registration (e.g., by
  issuance of a certificate of incorporation, registration number, etc.)
  or created or recognized by a Government  Agency (e.g. under a
  charter, treaty, convention, or equivalent recognition instrument);

  (2) The entity designated with the Incorporating or Registration
  Agency a Registered Agent, a Registered Office (as required under the
  laws of the Jurisdiction ofIncorporation or Registration), or an
  equivalent facility;

  (3) The entity is not designated on the records of the Incorporating
  or Registration Agency by labels such as “inactive,” “invalid,” “not
  current,” or the equivalent;

  (4) The entity has a verifiable physical existence and business
  presence;

  (5) The entity’s Jurisdiction of Incorporation, Registration, Charter,
  or License, and/or its Place of Business is not in any country where
  the CA is prohibited from doing business or issuing a certificate by
  the laws of the CA’s jurisdiction; and

  (6) The entity is not listed on any government denial list or
  prohibited list (e.g., trade embargo) under the laws of the CA’s
  jurisdiction.


Does OpenPGP encryption mean that not even I can see my data? Say I have an email and I want to send it to someone else. I encrypt it with his public key. This ensures that only he can read my message. Does this also means that I won't be able to read it? If so, how will I know what I have sent?

It's perfectly true. Encrypting an e-mail with someone public key, you get as output a ciphered text that you cannot decrypt yourself, this is the point of asymetric cryptography after all.

There are many methods to keep the original text.

keep it as clear-text
encrypt it with your own public key (to keep confidentiality)


Does KDE System Tray Extra Items "Clipboard" have the same security threats as the system clipboard? Does the clipboard under kUbuntu's KDE System Tray > Extra Items "Clipboard" have the same security threats as the system clipboard?

The following articles point out the insecure nature of the clipboard:
Is clipboard secure?

Is a password in the clipboard vulnerable to attacks?

How can I protect myself from this kind of clipboard abuse?

Can a malware steal the content of the clipboard?

The reason I ask is because I just realized that when I use the program xsel to clear my clipboard:

sudo apt-get install xsel
xsel -bc

My system clipboard is clear but all the contents are still available from kUbuntu's
KDE System Tray > Extra Items "Clipboard".

Does it carry the same security concerns as the system clipboard?

Note: I am aware there are many points of vulnerability a system has as it relates to information in RAM and on disk. This question is specifically about contents in the known 'system' clipboard as discussed in the attached links, and unknown clipboards (other places I don't know about that store what I right-click-copy or CTRL + C). Clearing the clipboard is one of many security measures and has it's cases of uselessness in certain types of attacks. Nonetheless I am still curious about these 'other' clipboards and if their vulnerabilities are essentially the same as the system clipboard.

All processes running as your user can read the contents of your clipboard and modify the contents. The KDE clipboard, called Klipper when I last used KDE, also stores previous clipboard history. It stores it by default in a text file. This means that the contents can be recovered from your hard drive by a forensics examiner or malware. You can disable this functionality however, causing it to only be stored in memory. All processes running as your user can still read and modify the clipboard, of course. If malware runs as your user, it has the same abilities you do. Always remember that.

With your system clipboard, the following is possible:

Processes running as your user can read the clipboard contents
Processes running as your user can modify the clipboard contents

With the KDE clipboard, the following is possible (by default):

Processes running as your user can read the clipboard contents
Processes running as your user can modify the clipboard contents
Processes running as your user can read your clipboard history
Processes running as your user can modify your clipboard history
Processes running as root can read very old deleted clipboard history
Forensic examiners / people with access to the drive can read very old deleted clipboard history

The last two bullet points can be disabled. When I last used KDE, this was possible by setting a limit to the history size. When the size is set to unlimited, it will save it to a text file on the drive. When the size is a numeric value, the history will be stored in memory only. You might also have to set it to not remember history across reboots. Or something like that.

I would like to note something however. It sounds to me like you are under the impression that individual applications are able to provide you with security against other programs which runs as your own user. If you indeed are still under the impression that you can protect your system from things like keyloggers running as your user, it is time to be disillusioned. Everything you type can be recorded by programs running as your user. Linux provides inter-user isolation, not intra-user isolation. This means that your browser, if it is compromised, can keylog that user. I've talked about this a bit here and here, and there is an excellent writeup about the problem of assuming intra-user isolation.


Is there security in the 1-wire protocol? I know that the 1-wire protocol has a slower communication and that it can be physically accessible and there other ways to get the information from the data bus.

I can't seem to find much information about security in this protocol, for what I have seen, I consider it insecure, I don't see any form of security applied to it.

Do you consider this protocol insecure as well? or I'm missing something?

The 1-wire protocol does not have any built-in security at all. But it shouldn't have any either, since the 1-wire protocol is on the layer 2 of the OSI model.

However, depending on the devices you hook up on 1-wire, there is possibility to add security. There are 1-wire chips that can do encryption and/or authentication without problems, for example as pointed out in comments about the DS1961S chip.
And this is something that is then done on the application layer (layer 7) of the 1-wire network.

A 1-wire network can be compared with the "ethernet protocol" or "RS232 protocol", or even "433,92 Mhz wireless", or IR communication between a TV remote and TV set. Its just a transmission medium for sending payloads. The payload can of course contain more advanced packets, for example IPv4/IPv6 packets if you want. One example of routing IPv4/IPv6 packets over RS232 is PPP protocol (Point to Point Protocol), where PPP protocol is a protcol that contains built-in security (but nowadays very bad security).

So in short: 1-wire is as secure as you make it.


DEK, KEK and Master key - simple explanation This article is intended to be a simplified explanation sans drill-down for people wanting to understand these concepts/terms.

What are DEK, KEK and MEK/Master key?

Secure Storage

DEK: Data Encryption Key
KEK: Key Encryption Key

Master Key: Generally will describe one of the two above keys.  Depending on the scheme in which it is implemented.

This type of encryption scheme is often used for secure storage.  Microsoft Windows is known to use this type of encryption scheme to protect user credentials and other types of data that are secured for a user.

Microsoft generates a Key Encryption Key using the user's password.  This KEK is then used to encrypt what they call the Master Key.  The Master Key is really a Data Encryption Key.  It will be used to encrypt any data that is put in the user's protected storage.

Key management for Full Disk Encryption will also work the same way.  The FDE software will randomly generate a DEK, then use the user's password/keyfile/smart card to create a KEK in order to encrypt the DEK.  This mechanism allows the user to change their password without having to decrypt and re-encrypt the entire volume.  Instead, the DEK is just re-encrypted with the new KEK.

Secure Protocols

Master keys as you hear them used in SSL/TLS or SSH are different.  Generally speaking the shared secret with be mixed with a secure algorithm so that both parties can generate a Master Key.  The Master Key is then used to generate the Encryption Keys, Integrity Keys, and Initialization Vectors for both sides of communication.  Here is how those keys are derived for SSL/TLS.


Why is CertificateVerify message necessary? (Why isn't client authentication done through the KeyExchange) Why is client authentication not done through the KeyExchange like with the server, but through a CertificateVerify message?
When using RSA key exchange the client encrypts the key material with the server's public key so only the real server (which has the private key) can decrypt it. [RFC5246: 7.4.7.1] Why doesn't the client also sign the key material with its private key when using client authentication?
When using Diffie-Hellman key exchange the server signs it's key parameters using its private key to prove it has the private key (and therefore is the real server). [RFC5246: 7.4.7.2] Why doesn't the client sign it's parameters too when using client authentication?
Instead of these (I think more logical) methods, the client sends a CertificateVerify message with a signature over all handshake messages. Why is this method chosen?
This only applies to certificates with signing ability, because with eg. static DH certificates client authentication is performed during the KeyExchange. [RFC5246: 7.4.8]

Your idea doesn't work. Being able to signing the key material doesn't prove that the client has the private key corresponding to the certificate.

Authentication is usually done by a challenge-response protocol in which one party presents a question and the other party provides a valid answer to prove that it knows the rule of transforming questions to answers. The key material (here acts as the question) in the ClientKeyExchange is determined solely by the client while the server doesn't have any control over it. So it's just like making the client answer its own question. Without knowing the "rule" (the private key), the client can still provide a valid answer (signed key material). For example, an attacker can take the certificate and the signed key material from another client and later impersonate that client when communicating with the server. To get the certificate and signed key material from the victim, the attacker can establish his own server and make somebody connect to him.

Actually, the signed hash in the CertificateVerify message includes information from both the client and the server (i.e. the "question" is determined by both sides). So the client is not answering its own question.
Client authentication is optional in an SSL/TLS transaction. Considering clarity and ease of implementation, it's not a good idea to have a message with two forms.

The CertificateVerify message is not strictly necessary. It is OK to merge it into the ClientKeyExchange as long as the materials to sign are carefully chosen. However, it is better to have a separate message since it plays an independent role. By the way, a separate message doesn't necessarily cost an additional TCP segment. It's very common to embed multiple messages in one segment so a separate message won't introduce extra costs.


Does bcrypt have a maximum password length? I was messing around with bcrypt today and noticed something:

hashpw('testtdsdddddddddddddddddddddddddddddddddddddddddddddddsddddddddddddddddd', salt)
Output: '$2a$15$jQYbLa5m0PIo7eZ6MGCzr.BC17WEAHyTHiwv8oLvyYcg3guP5Zc1y'

hashpw('testtdsdddddddddddddddddddddddddddddddddddddddddddddddsdddddddddddddddddd', salt)
Output: '$2a$15$jQYbLa5m0PIo7eZ6MGCzr.BC17WEAHyTHiwv8oLvyYcg3guP5Zc1y'

Does bcrypt have a maximum password length?

Yes, bcrypt has a maximum password length. The original article contains this:

  the key argument is a secret encryption key, which can be a user-chosen password of up to 56 bytes (including a terminating zero byte when the key is an ASCII string).

So one could infer a maximum input password length of 55 characters (not counting the terminating zero). ASCII characters, mind you: a generic Unicode character, when encoded in UTF-8, can use up to four bytes; and the visual concept of a glyph may consist of an unbounded number of Unicode characters. You will save a lot of worries if you restrict your passwords to plain ASCII.

However, there is a considerable amount of confusion on the actual limit. Some people believe that the "56 bytes" limit includes a 4-byte salt, leading to a lower limit of 51 characters. Other people point out that the algorithm, internally, manages things as 18 32-bit words, for a total of 72 bytes, so you could go to 71 characters (or even 72 if you don't manage strings with a terminating zero).

Actual implementations will have a limit which depends on what the implementer believed and enforced in all of the above. All decent implementations will allow you at least 50 characters. Beyond that, support is not guaranteed. If you need to support passwords longer than 50 characters, you can add a preliminary hashing step, as discussed in this question (but, of course, this means that you no longer compute "the" bcrypt, but a local variant, so interoperability goes down the drain).

Edit: it has been pointed out to me that although, from a cryptographer's point of view, the article is the ultimate reference, this is not necessarily how the designers thought about it. The "original" implementation could process up to 72 bytes. Depending on your stance on formalism, you may claim that the implementation is right and the article is wrong. Anyway, such is the current state of things that my advice remains valid: if you keep under 50 characters, you will be fine everywhere. (Of course it would have been better if the algorithm did not have a length limitation in the first place.)


Is there any checklist for website security? Is there a standard checklist to audit an organization's website security?

There is the OWASP checklist here: OWASP Testing Checklist

Recently some people have collaborated on a checklist for developers: A practical security guide for web developers

I found the second one to be more useful myself, although the OWASP list has been around for much longer.


Security of remailers A layman's question: If I don't err, with remailers or analogous systems one sends a message to a node of a chain of nodes, which collectively perform the entire transmission. However, the message to the first node of the chain must IMHO contain a valid IP-address of the sender.
So, if the agencies have access to that very first seqment of the transmission, the sender
could be found out (unless one sends from internetcafes or callshops). Is this correct?

Decent remailers who aim at providing anonymity use mix networks with encryption.

The sender wants to send his message M through the chain of remailers A, B and C (in that order). To do that, the sender encrypts the message M (complete with headers such as subject and destination address) with the public key of C. That encrypted message is then packed into another message with the address of C as destination address; that outer message is then encrypted again, this time with the public key of B. The result is again wrapped into a message with B's address as destination. That message is encrypted with A's public key, and then sent to A.

When A receives the message, it decrypts it and finds out an inner message to be sent to B. B itself will be able to decrypt it, and find the inner-inner message which is for C. C will decrypt that, and find the inner-inner-inner message M and the actual destination. That way, A won't be able to know where the message should go; also, C won't be able to know from where the message comes (because C received it from B, not from the sender). B knows nothing at all (from the point of view of B, the message is from A and sent to C).

This principle is also applied to HTTP requests in Tor, and can also be used to design electronic voting systems.


Forced to use using 2-Step Authentication to keep online profiles safe? I am starting to see a majority of services, websites, and social networks offering the 2-step Authentication like crazy now to protect their users. Also, after reading how the Twitter Account N was hacked, 2-Step Authentication to protect our accounts online seems like a requirement more and more.

There is even a website to help see which services uses it and doesn't use it at Two Factor Auth (2FA).

I have had several major hacking attempts all over my social networking profiles, and own personal websites which I administrate and help run.

I also feel like we have to use it, or else we will have our banking accounts accessed and comprised.

With my last month experiences, I had 107 loggin attempts text messaged to me from my PayPal and Facebook account. They all failed, but if it wasn't for the login code texted to my phone, I would of had money taken out of my account.

Are we now forced to use 2-Step Authentication to keep our accounts and assets secure now? Should we make this a web standard to make sure people are secure to just visit our websites and services?

Forced? No. But passwords alone have known weakness. Using 2-factor methods help to mitigate the risks of those weaknesses.

That also means that we can't make it a web standard for every login, because there are instances where it does not make sense in terms of mitigating those risks.

I suspect that the current 2-factor is a stepping stone to better things. Biometrics and physical tokens can be combined to provide something similar to 2-factor and people are working on making that accessible for the masses.


What security aspects must online assessment sites consider? When building an online assessment site that let students take the examination via their own devices (but they are all in the same room during the examination), what kind of security vulnerabilities must the online assessment site consider?

I need a list of some possible security issues, scamming acts, etc to consider. For example, for the sake of money, one student A is paid by another student B to login with B's credentials and to do the examination.

How to prevent each issue from happening is also welcome!

I need a list of some possible security issues

Could be almost anything on this list. Just to select some from the top ten list on owasp:

Injection -

  Injection flaws occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

Broken Authentication and Session Management -

  Application functions related to authentication and session management are often implemented incorrectly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws.

Cross-Site Scripting (XSS) -

  XSS can occur whenever an application  accepts untrusted data in a new web page without proper validation or escaping, or updates an existing web page with user supplied data. XSS allows attackers to execute scripts in the victim’s browser which can hijack user sessions, deface web sites, or redirect the user to malicious sites.

Broken Access Control -

  Restrictions on what authenticated users are allowed to do are not always properly enforced. Attackers can exploit these flaws to access unauthorized functionality and data, such as access other users' accounts, view sensitive files, modify other users’ data, change access rights, etc.

Security Misconfiguration -

  Good security requires having a secure configuration defined and deployed for the application, frameworks, application server, web server, database server, platform, etc. Secure settings should be defined, implemented, and maintained, as defaults are often insecure. Additionally, software should be kept up to date.

Sensitive Data Exposure -

  Many web applications and APIs do not properly protect sensitive data. Attackers may steal or modify such weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data deserves extra protection such as encryption at rest or in transit, as well as special precautions when exchanged with the browser.

Insufficient Attack Protection -

  The majority of applications and APIs lack the basic ability to detect, prevent, and respond to both manual and automated attacks. Attack protection goes far beyond basic input validation and involves automatically detecting, logging, responding, and even blocking exploit attempts. Application owners also need to be able to deploy patches quickly to protect against attacks.

Cross-Site Request Forgery (CSRF) -

  A CSRF attack forces a logged-on victim’s browser to send a forged HTTP request, including the victim’s session cookie and any other automatically included authentication information, to a vulnerable web application. Such an attack allows the attacker to force a victim’s browser to generate requests the vulnerable application thinks are legitimate requests from the victim.

Using Components with Known Vulnerabilities -

  Components, such as libraries, frameworks, and other software modules, run with the same privileges as the application. If a vulnerable component is exploited, such an attack can facilitate serious data loss or server takeover. Applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.

Underprotected APIs -

  Modern applications often involve rich client applications and APIs, such as JavaScript in the browser and mobile apps, that connect to an API of some kind (SOAP/XML, REST/JSON, RPC, GWT, etc.). These APIs are often unprotected and contain numerous vulnerabilities.

I think the main ones you should focus on are injection and cross site scripting.


Is there a way to download a PHP file without it being executed? I recently got a phishing mail of unusually bad quality; "Please imediatly sign in under the following link, as we are your bank, you know"-ish. The link points to an unconvincing URL with .php at the end.

I was asking myself why they might use a PHP script instead of just faking the look of the given page and submitting entered data to a form.

I don't really want to click the link to find out, but I would love to get to know what this PHP file is about to do. Is there a way of downloading the script, such as you could with the client-sided JavaScript?

Or am I not able to access the PHP file, as it is executed by the server?

Are there other ways of analyzing this file and its behavior without any danger?

If the server is configured correctly, you cannot download a PHP file. It will be executed when called via the webserver. The only way to see what it does is to gain access to the server via SSH or FTP or some other method.

This is because PHP is a serverside language, all the actions are performed on the server, then the result is sent to your browser (which is clientside).

If you are afraid to mess with your system, you could use Virtualbox with an Ubuntu VM and open the page from there. If you take a snapshot of the VM after installing, and before doing dangerous things, you can later go back to that snapshot and undo anything the script could have done to the VM.


Progress in market approaches to software vulnerability disclosure? In  A Comparison of Market Approaches to Software Vulnerability Disclosure (2006), Rainer Böhme describes the profound role of economic "market failure" in the industry dynamics that hinder software security.  He also describes 4 kinds of markets that can help:

Bug challenges, like payments by Mozilla and Google for security bugs
Vulnerability brokers, aka “vulnerability sharing circles”, e.g. CERT or iDefense
Exploit derivatives, an application of binary markets to security events
Cyber-insurance

The latter two seem to be the most promising.  Have either of these ideas matured since then, and are they available anywhere?
See also

Exploit Derivatives & National Security - Micah Schwalb - 9 YALE J. L. & TECH. 162 (2007)

Which companies facilitate payment in return for vulnerability disclosure?

Update:

New index a step to trading IT security risks - CRN Australia which talks about the Index of Cyber Security

Update 2: I just ran across Tyler Moore's paper on misaligned incentives and information asymmetries, and getting ISPs to take more responsibility: Introducing the Economics of Cybersecurity: Principles and Policy Options (pdf) National Academies Press, 2010

Of these market types, the first two can benefit individual security researchers, but must be initiated by the vendor. Therefore, only vulnerability information regarding vendors participating in such a solution would be valuable under such a mechanism. Depending on the level of participation, this could deeply hamper a security researcher. Vulnerability brokers and cyber-insurance don’t have an immediate incentive for the individual researcher. It
would be difficult to leverage a found vulnerability into income under these two systems.

Due to the secretive nature of the market at the present time, it is difficult for them to find a buyer, determine a price for the information, prove the value of the vulnerability, and exchange the goods for money. On top of this, at any point in this process, the vulnerability may be announced by someone else, making the discovery worthless.
Some solutions exist which help to alleviate some of these problems, however their actual implementation remains far off in the future.

Take a look at this paper: http://securityevaluators.com/files/slides/cmiller_auscert2008.pdf


"reflected" XSS attacks delivery to the victim My Question is specific to reflected XSS attacks.

Are reflected cross site scripting attacks mostly possible when the injectable parameter is part of the URL ? I know vulnerable parameters in header can also be used to launch attacks using flash and other client side technologies.
However I implied to this since in most of the execution cases of this attack, requires the victim to click on the crafted URL. Could anyone please explain if there are other ways also (reflected XSS only). Examples would help.

Reflected XSS is possible if the parameter is part of the URL (usually in the query string) or part of the message body in a POST request.

Parameters in headers or cookies cannot usually be used in a reflected XSS attack because there is no way for an attacker to set these headers (custom headers cannot be sent cross-domain without the use of CORS).

They don't always require a click from the victim on the infected URL directly. Say if a website the user usually visits was compromised, the attacker may add

<form method="post" action="https://example.com/submit">

  <input type="hidden" name="textarea1" value="&lt;input onclick=alert(document.cookie)&gt;" />

</form>

<script>
document.forms[0].submit();
</script>

to the HTML (watering hole attack).

Note that if a web page is vulnerable to a POST body reflected XSS attack, then this can also be mitigated via anti-CSRF protections instead of proper HTML output encoding (although in the spirit of defense in depth I would also recommend fixing the actual XSS vulnerability because there might be other attack vectors which could exploit this).


Where can I find a canonical list of elliptic curve names and their aliases? I recently had a problem where I created an EC client certificate which used the sect571k1 curve and I got some strange errors attempting to use it as a client certificate through Mozilla Firefox. It turns out that Firefox supports secp521r1 but not sect571k1.

I had created the certificate using Java's keytool, which reports the curve as 570-bit EC key, while openssl x509 tells me it is both ASN1 OID: sect571k1 and NIST CURVE: K-571. A bit of googling leads me to RFC 4492 which lists several keys and their various aliases, but it does not list many of the curves which are popularly discussed such as djb's Curve25519 and any of the brainpool curves. (Java's keytool doesn't appear to allow you to choose the exact curve, only the bit-size of the key, so I didn't really have a choice.)

My LibreSSL supports ~90 different curves while my Java supports ~50 different curves. I'd like to be sure that anything I do with any "more-capable" tools are going to be compatible with web browsers, and it would be good to know what the equivalents are for all of these names.

For TLS there is of course the official list of curves, but there's not a single, comprehensive list of elliptic curve names I am aware of. But when you look at different TLS implementations, you will quickly notice that there is only a limited number of elliptic curves that are supported by all major implementations.

For maximum interoperability, you should use secp256r1 (NIST P-256) or secp384r1 (NIST P-384), as these are used by most CAs for their own certificates, are supported by all major TLS implementations and will also be contained in TLS 1.3 (which only contains a total of five curves (secp256r1, secp384r1, secp521r1, curve25519 (x25519) and curve448 (x448)).

Curve25519 will probably play a major role in the future, as it has has many desirable properties (very fast, easy to implement, avoids leaking information via side channels), but has only recently been included in many important standards.


What attacks are made possible by public release of my web history? Assume that my Internet history is made public (accidentally or on purpose). And this release is over 24 hours since the visits were made.

Also, assume that there aren't embarrassing sites on there: there isn't any blackmail potential.

(My most embarrassing page visited in the last week is actually the TV tropes page for my little pony, for which I have a valid reason and a witness).

What potential attacks does this allow? I'm mildly concerned about seeing massive links like:

  hxxps://kdp.amazon.com/en_US/ap-post-redirect?openid.assoc_handle=amzn_dtp&aToken=Atza%7CIwEBIO9mWoekr9KzK7rH_Db0gp93sewMCe6UcFPm_MbUhq-jp1m7kF-x0erh6NbjdLX3bm8Gfo3h7yU1nBYHOWso0LiOyUMLgLIDCEMGKGZBqv1EMyT6-EDajBYsH21sek92r5aH6Ahy9POCGEplpeKBVrAiU-vl3uIfOAHihKnB5r2yXPytFCITXM70wB5HBT-MIX3F1Y2G4WfWA-EgIfZY8bLdLangmgVq8hE61eDIFRzcSDtAf0Sz7_zxm1Ix8lV8XFBS8GSML9YSwZ1Gq6nSt9pG7hTZoGQns9nzKLk7WpAWE8RazDLKxVJD-nDsQ9VdBJe7JZJtD7c77swkYneOZ5HXgeGFkGhKsMnP7GSYndXhC_PqzY251iDt0X7e5TWvh86WZA0tG2qZ_lyIagZtB3iw&openid.claimed_id=https%3A%2F%2Fwww.amazon.com%2Fap%2Fid%2Famzn1.account.AEK7TIVVPUJDAK3JIFQIQ77WZWDQ&openid.identity=https%3A%2F%2Fwww.amazon.com%2Fap%2Fid%2Famzn1.account.AEK7TIVVPUJDAK3JIFQIQ77WZWDQ&openid.mode=id_res&openid.ns=http%3A%2F%2Fspecs.openid.net%2Fauth%2F2.0&openid.op_endpoint=https%3A%2F%2Fwww.amazon.com%2Fap%2Fsignin&openid.response_nonce=2018-12-11T13%3A46%3A52Z4004222742336216632&openid.return_to=https%3A%2F%2Fkdp.amazon.com%2Fap-post-redirect&openid.signed=assoc_handle%2CaToken%2Cclaimed_id%2Cidentity%2Cmode%2Cns%2Cop_endpoint%2Cresponse_nonce%2Creturn_to%2CsiteState%2Cns.pape%2Cpape.auth_policies%2Cpape.auth_time%2Csigned&openid.ns.pape=http%3A%2F%2Fspecs.openid.net%2Fextensions%2Fpape%2F1.0&openid.pape.auth_policies=http%3A%2F%2Fschemas.openid.net%2Fpape%2Fpolicies%2F2007%2F06%2Fnone&openid.pape.auth_time=2018-12-11T13%3A46%3A52Z&openid.sig=5cx5iHjeLyWTTA9iJ%2BucszunqanOw36djKuNF6%2FOfsM%3D&serial=&siteState=clientContext%3D135-4119325-2722413%2CsourceUrl%3Dhttps%253A%252F%252Fkdp.amazon.com%252Fbookshelf%253Flanguage%253Den_US%2Csignature%3DgqJ53erzurnmO1SPLDK1gLwh9%2FUP6rGUwGF2uZUAAAABAAAAAFwPv8dyYXcAAAAAAsF6s-obfie4v1Ep9rqj

in my history and worrying that secure information might be passed in a URL somewhere.

I am aware that this makes it easier to impersonate my identity, and I'm mostly interested in the leakage of information via the URL itself.

I have a general interest, but this is motivated by a test project I'm running.

Your question might be more undefined than you realise. Any kind of data can be passed using URL parameters. Usernames, passwords, authentication tokens, settings, form data, or anything the web developer chooses. It's not always good practice to use URL parameters to for this, but it is always possible.

And it's entirely up to each individual web developer on each individual page (not just site) as to what might be exposed and when. So you might not be able to predict what might be exposed.

So, to answer your question, in the worst case, you could experience a complete and utter disclosure of any amount of personal data including credentials.

By request, I did a search for the practice of "passwords in URL parameters" and restricted results to this year. Here's one of the top hits:

https://answers.splunk.com/answers/622600/how-to-pass-username-and-password-as-a-parameter-v.html

That's a forum from Feb 2018 from a major, publicly traded company talking about how to do this.

Here is OWASP's official page on this vulnerability:

  The parameter values for 'user', 'authz_token', and 'expire' will be
  exposed in the following locations when using HTTP or HTTPS:

  Referer
  Header  Web Logs  Shared Systems  Browser History  Browser Cache
  Shoulder Surfing


Can serving HTTPS to Internet Explorer on Windows XP be made secure? Answers to Why is HTTPS not the default protocol? state that a lot of sites still use clear HTTP instead of HTTPS because all of these are true:

A substantial number of visitors to the site use Internet Explorer 6, 7, or 8 for Windows XP (IE/XP).
IE/XP can see only the first certificate on port 443 of a given IP address because it uses Windows XP's TLS library, which lacks support for Server Name Indication (SNI).
(Chrome and Firefox on Windows XP use different TLS libraries that support SNI.)
The site shares an IPv4 address with another HTTPS site because it can't afford an increasingly scarce dedicated IPv4 address.

However, as of April 2014, extended support for IE/XP and the rest of Windows XP has ended. This means there are defects in IE/XP that Microsoft will no longer fix. A malicious actor could install unwanted software by exploiting a zero-day vulnerability resulting from one of these defects, which would defeat the confidentiality purpose of HTTPS in either of two ways:

A keylogger could capture all payment credentials, such as credit card numbers and Amazon or PayPal passwords, that an IE/XP user enters into HTTPS sites.
A proxy and certificate authority running on the local machine could perform a man-in-the-middle (MITM) attack on all the user's HTTPS connections.

What factors should a website's operator weigh when determining whether to continue to attempt to serve secure pages to IE/XP users? Are there any overwhelming arguments as of the first quarter of 2015 for accommodating or blocking IE/XP on a secure site?

Fast answer

No!

Acceptable workaround

Even an HTTPS connection from IE or Windows XP can't be considered as
secured by a normal and even a skilled user. It was a known weak combination long before Microsoft announced its support deadline.

Hence I would suggest a 2 steps approach for a webserver architect.

Detect the referer, and if it is IE any version or XP any version,
 redirect client toward a web page indicating that you identified he is connecting from a computing environmnet which is known as unsecure.
Clearly assert you can't be hold responsible for any spy upon his connection which might occur at the level of his computer and his choosen software.
Ask him if he accepts the risk involved and want to proceed with an
 insecure connection even with the infamous small lock which might be displayed, even with your server URL starting with https:// and even with the high grade certificates you installed on your web server. Upon explicit agreement from the user, redirect him toward the core of your webserver through HTTPS. Upon disagreement, congratulate him for making a good choice and hope to see him back soon within an environment of full trust.

This will be a correct communication informing your customers and at the same time offering them a chance to brain storm and improve, one day, their security :).


Using a persistent httpOnly cookie for authentication? (SPA) So I'm building an application that needs authentication, I'm wondering if there's an security concerns with using a persistent httpOnly cookie to store user authentication with a SPA? (only 1 server. OAuth is not an option) I could set the duration to say 30 days (is this a reasonable duration or should it be shorter?), then every time the user accesses the site a new token is set. This would mean that users visiting the site more than 30 days apart would need to relogin, but other than that it would be user friendly and secure from my understanding?

One thing I'm not sure about is the format of the token, since typically JWTs can't be revoked from my understanding, so would a long (128bit?) random string be sufficient instead?

User logs in -> Generate token -> Push token to DB with the users ID (1 token per user, remove any existing tokens?) -> Set cookie to token.

User starts browser -> Get token from cookie -> Search DB for matching tokens -> accept / reject

User accesses resource -> Get token from cookie -> Search DB for matching tokens -> Get associated user ID -> Authorize if permitted to access resource

User logs out -> Search DB for token, remove entry

A few thoughts:

As @ConorMancone points out, this is just basic session management. Approximately every web site in the world that lets you submit credentials once (rather than on every authenticated request) and then stay signed in (whether for minutes or years) is doing some variant on this.
HttpOnly is not a significant security boundary. You need the Secure flag, which prevents the cookie from being sent over insecure connections. Not that HttpOnly is bad - if you can use it, do so - but all it does is prevent a specific post-exploitation attack if the attacker successfully uses XSS (Cross-Site Scripting). Preventing XSS in the first place is far more important, as it can be used for lots of things besides stealing cookies. You can also use the relatively new "SameSite" flag - probably in "Lax" mode - for CSRF protection.
The primary use of JWTs is to let servers authenticate clients without storing any state on the server. This is most beneficial for apps that are big enough they are served by a cluster; otherwise, active user sessions are often cached on the server to avoid the extra DB query (but using a cluster means you now have to deal with cache coherency messes). You can also switch what your session token looks like at any time; to the client it's just a meaningless blob that gets included with every request.
If you want to use random tokens, 128 bits (16 bytes) is good. However, you must use a cryptographically-secure (pseudo-)random number generator to create the token (you'll also need to encode the token as something, like hex or HTTP-safe base64). Every modern OS and web framework offers this.
Speaking of web frameworks, I can't really recommend rolling your own session management functionality. Just use whatever your framework provides for sessions. It might not be the best, but it'll probably be better than you can create without more knowledge and experience.
Session duration is a question that REALLY depends on the app, and the clients, too much for us to say here. Some apps, such as banking apps or other very conservative ones, often have a session timeout measured in minutes. Others, such as StackExchange, are good for much longer (looks like the "acct" cookie SE uses is good for 6 months; some sites' cookies are good for years). You can also just not set an expiration, in which case the cookie lasts as long as the browser session (but no longer). Since lots of people don't actually close their browsers these days, those cookies may last until something forces the user to reboot.


Quick scan of a /8 subnet with nmap I am trying to scan a full subnet (10.0.0.0/8) using nmap. I am using the command nmap –v –sn 10.0.0.0/8. I specifically just want to detect active hosts without scanning ports because I thought that would speed up the process. However when I do this it doesn’t seem to move fast at all. So far I am up to 8 hours in the scan and I am nowhere near close to finishing. Is there a quicker way to scan the entire subnet to look for active hosts using nmap?

I would like to throw in that the link provided by user ximaera omits some information.

Using a scan like this

nmap -T5 -n --max-parallelism=255 --min-parallelism=100 -sn 10.0.0.0/8

could trip up some security mechanisms, because it can look a bit like a ping flood and it does not necessarily offer an increase in speed.

I would suggest omitting the parallelism options and scanning like this

nmap -T5 -n -sn 10.0.0.0/8


Confidentiality doesn't provide integrity, but it does enable it? I've heard it stated that it is a common misconception that encryption provides data integrity.

A highly voted question on this topic - Does encryption guarantee integrity? - has some very insightful answers. For instance, the top voted answer states:

  No. This is easy to see if you consider the one-time pad, a simple
  (theoretically) perfectly secure system. If you change any bit of the
  output, a bit of the clear text will change, and the recipient has no
  way to detect this.

That makes perfect sense, so I think it's clear that the answer to does encryption guarantee integrity is clearly no, but is it correct to state that encryption enables some other means of integrity verification, because an attacker may need to break confidentiality to determine what modification of a message can be applied and not be detected if a higher level integrity check on the data is applied?

For instance if a message already has some defined structure that a receiver is expecting(ie - only a subset of possible bit modifications would be valid), and the act of hiding the contents of that message makes it very difficult for an attacker to correctly select one of those possible modifications(or in fact if they have no information, the best they can do is randomly change bits), then in that case, encryption at least enables integrity, correct? Or viewed another way, because encryption could force an attacker to at best randomly change bits of the cipher text, then this could allow some pre-existing information to serve as some type of (perhaps not effective) integrity check? ie - changed bits could cause misspellings in a document, or could cause an encrypted code file to no longer correctly compile, despite a receiver somehow knowing the sender would not have misspelled those specific words, or would have sent compiling code.

Updated to make the explanation clear

Whether or not a given message follows a particular syntax is a very weak integrity check. It could also be a bug on the sender side which could result in messages not being of a particular format.

As mentioned in this answer, many common ciphers are trivially malleable. This means that it is possible to modify the encryption text to generate valid plaintexts. You are trying to go a step further by ensuring that the set of valid plaintexts is smaller. Sure, that makes the task a bit harder for the attacker but given enough time and datasets,  the attacker may be able to pass your integrity check as well.

Consider the following scenario:
Alice is talking to Bob and Eve is listening to the conversation. They are using block cipher for confidentiality. After listening to the conversation for a while, Eve has enough ciphertexts to play with the block cipher that they are using. The next message that Alice sent is intercepted by Eve, merged with some other previous ciphertext and Bob is able to decrypt it and see that the format is correct. This message passes the integrity check even if it is a forgery.


Memory Corruption in C/C++ I'm doing a study on Memory Corruption. I need to compile a list of all the exploitable memory corruption issues that have been recognized till date and provide a sample vulnerable code for it.

I need help from the community. I tried searching but was unable to find any such list.

Things that I have compiled

Stack Overflow
Heap Overflow
Off by One Byte
Uninitialized variable memory bug exploitation
Signed/Unsigned bugs
User after free
Double Free
?????

Please correct me if the list is wrong. I need a list of all the exploitable bugs in software written in C/C++.

Thanks.

You might want to check the CWE (Common Weakness Enumeration) catalog for this type of research: http://cwe.mitre.org/index.html

The closest entry is probably CWE-633: CWE-633: Weaknesses that Affect Memory

I really like the CWE when it comes to categorize bugs (also check the "Relationships" for each entry). Each entry comes with an explanation and possible CVEs.

The CAPEC might also be interesting: (capec.mitre.org/index.html)

Note that integer coercion (CWE-192) or integer overflow (CWE-190) might just lead to bad calculation but not necessarily to a memory problem (see CWE-680).


DNS Server Recursive Query Cache Poisoning Weakness "Bounce DoS" Tenable Nessus states that if there is a DNS Server Recursive Query Cache Poisoning Weakness the host allows recursive queries via UDP, then the host can be used to 'bounce' Denial of Service attacks against another network or system.

What is a bounce DoS attack and what is the importance of UDP in it?

Basically, the DNS Cache poisoning (also known as DNS spoofing) consists in:

An attacker attempts to insert a fake address record for an Internet domain into the DNS. If the server accepts the fake record, the cache is poisoned and subsequent requests for the address of the domain are answered with the address of a server controlled by the attacker. For as long as the fake entry is cached by the server (entries usually have a time to live (TTL) of a couple of hours) subscriber's browsers or email servers will automatically go to the address provided by the compromised DNS server.

Here is a link explaining it.

The more important the dns server that has been compromised, the greater number of requests will be received and the users of other DNS servers that use it as a forwarder will also be affected. That's the "bounce" you are talking about.

And to answer to your question how important is UDP?. Is as simple as UDP is the protocol used for DNS requests. TCP is only used for zone transfers. So every request is travelling as UDP. And as you know (I guess), UDP packets work in a similar way to TCP but they throw all the error-checking stuff out. All the back-and-forth communication and deliverability guarantees slow things down, so UDP usually is better to perform DoS because is faster.

Here is another interesting article. On this, it's explained very well how to use a DNS server to be part of a DDoS (Distributed Denial of Service) attack.