Problems with in Browser Crypto There are lots of older articles1 on why in-browser crypto is a bad idea. Most are summed up via: http://bitwiseshiftleft.github.io/sjcl/

  We believe that SJCL provides the best security which is practically available in Javascript. (Unforunately[sic], this is not as great as in desktop applications because it is not feasible to completely protect against code injection, malicious servers and side-channel attacks.)

It seems the biggest problem they mention is that an attacker could serve you bad javascript that the browser executes because XSS is so common.

Between TLS and an extremely restrictive Content Security Policy, is this still an issue and therefore in-browser crypto a bad idea?

The goal of the encryption is not to replace TLS. It is being used to encrypt documents before they reach the server so only the sender and recipient can read them.

1:

https://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/
https://tonyarcieri.com/whats-wrong-with-webcrypto
https://www.nccgroup.trust/us/about-us/newsroom-and-events/blog/2011/august/javascript-cryptography-considered-harmful/

I've been hoping someone would ask about this topic, i've been doing a lot of research in the area.

You are correct that most of the points in javascript-cryptography-considered-harmful are outmoded by newer browsers. Aside from the obvious issue of someone compromising the server, which is a separate issue and presents a problem to TLS as well, the main points are now "fixed":

window.crypto.getRandomValues() uses a real CSPRNG
HTTPS is common and much cheaper now than in 2011
CSP's integrity and nonce <script> attributes can secure script delivery to make sure what's running is expected
SJCL is years more mature than in 2011, and no major issues are outstanding
malleable runtimes don't matter if you don't have XSS, which CSPs are now good at stopping

Furthermore, we now know that HTTPS is not an absolute guarantee of privacy (snowden/heartbleed/crime/breach/etc), but proper end-to-end encryption is. We can also now implement fairly robust, battle-tested, and secure libraries, backed by a more secure JS runtime than what was offered in 2011; "use strict" widely supported, a CSPRNG, binary structures, web workers with sealed runtime environments etc.

Those are updates to the main points, but if you have concerns about other aspects of client-cryptography, i'll be happy to address them.

Of course, nothing is perfect:

really old browsers still have issues or can't run new code securely
user-added extensions can run whatever code they want
malware can replace the whole browser with something sinister, or steal data pre-encryption
phishing can trick the user into using something besides your safe site.

In short, i think post-snowden, we should try to keep plain private data off servers wherever we can help it, and solid end-to-end encryption, done right, greatly enhances the privacy of your users and the security of their content.


Can ISO 7816 (EMV) based smart card handle interrupts? ISO 7816 smartcards are typically used in EMV transactions. I know that the card can perform arbitrary actions before sending a response to the terminal in a typical EMV transaction (e.g. signing dynamic data to generate SDAD). However, is it possible that the card perform a certain action while waiting for a command APDU from the terminal? That is the command APDU serves as an interrupt that is handled when it reaches the card, the card will stop what it was doing and service this command by sending a response.
Is this possible?

Contact card can. Contact card can even tell terminal to wait and call it again after some seconds and then it can do this indefinitely (21:01).
EMV Book 1, 9.2.2.3.1 Procedure Byte

The procedure byte indicates to the TTL (Terminal Transport Layer) what action it shall take next. Procedure Byte Value 60, the TTL shall provide additional work waiting time.

ICC can instruct terminal to wait by using this byte. The time is calculated as an elementary time unit (etu). A linear relationship exists between the etu on the I/O line and CLK frequency (f). etu cannot be used by ICC to count seconds. It sets duration of I/O line for transmission and reception mode as explained in EMV Book 1, 7 Physical Transportation of Characters and it's follow-up subsections.

During the transaction process, data is passed bi-directionally between the terminal and the ICC over the I/O line in an asynchronous half duplex manner. A clock signal is provided to the ICC by the terminal, and this shall be used to control the timing of this exchange.

I put forward your question to @Steven Murdoch (the researcher behind vulnerabilities in chip and PIN) to know if the reverse happens.

I don't think so, but I'm not aware of situations where it is necessary for the card to wait for the terminal. It's the terminal which is driving the exchange, so the card just waits for the terminal to do the next thing.

I think that something like that could be done but it might be unreliable if the terminal is not specifically designed to support this use case. Normally once terminals have completed their transaction, they turn off the clock so the card won't be able to do further processing.


Hash a list of strings in a collision-resistant way I have a list of strings that I need to compute the hash of, but I can't figure out how to do it in a way that would be resistant to collision attacks.

For example, in this python code:

def list_digest_1(strings):
    import hashlib
    hash = hashlib.sha1()
    for s in strings:
        hash.update(s)
    return hash.hexdigest()

There is a collision between [b'foo', b'bar'] and [b'foobar'].

This can be reduced by inserting a separator between the strings:

def list_digest_2(strings):
    import hashlib
    hash = hashlib.sha1()
    for s in strings:
        hash.update(s)
        hash.update(b'\0')
    return hash.hexdigest()

However, you can still easily craft a collision by injecting separator characters in the string, e.g. [b'foo\0bar', b'baz'] and [b'foo', b'bar\0baz']. This could potentially be avoided by sanitizing the strings or otherwise escaping the separator character, but I'd rather having to do this if possible.

Another possibility is to hash each string separately, and then combine the hashes:

def list_digest_3(strings):
    import hashlib
    hash = hashlib.sha1()
    for s in strings:
        hash.update(
            hashlib.sha1(s).digest()
        )
    return hash.hexdigest()

Note that I'm sill not sure if this actually solves the problem or just moves it a step back.

I'm not using the hash for a security-sensitive task, I'm just using it as a preliminary filter for some database queries, to reduce the performance hit from directly testing for equality every time.
I'd prefer to use something that is resistant to this sort of attack (in theory an attacker could artificially induce extra load by submitting collisions or something like that) but the third version performs significantly worse when there are a lot of small strings, limiting the performance reasons for using a hash function in the first place.

def rand_str(length):
    return ''.join(random.choice(string.ascii_uppercase + string.digits) for _ in range(length)).encode('utf-8')

def rand_list(length, str_length):
    return [rand_str(length=str_length) for _ in range(length)]

import tqdm
str_list = [rand_list(length=10000, str_length=2) for _ in tqdm.tqdm(range(1000))]

for hash_fun in list_digest_1, list_digest_2, list_digest_3:
    t = timeit.Timer(lambda: [hash_fun(s) for s in str_list])
    print('{}: {}'.format(hash_fun.__name__, t.timeit(number=1)))

# list_digest_1: 1.318927247000829
# list_digest_2: 2.4033974090016272
# list_digest_3: 7.667939508999552

How can I avoid this problem in computing the hash of a list of strings?
Also, if there is an existing python tool I should be using for this instead, I'd be glad to know of it.

You can use the following canonical form of an array of strings:

<fixedLen1>string1><fixedLen2><string2>...

Implementation:

def list_digest(strings):
    import hashlib, struct
    hash = hashlib.sha1()
    for s in strings:
        hash.update(struct.pack("I", len(s)))
        hash.update(s)
    return hash.hexdigest()


Heartbleed: Why does the client supply the length of the message at all? "The fix for this bug is simple: check that the length of the message actually matches the length of the incoming request."

Why do we even have the client report the length at all?

If we can know the length of the incoming request, can't we just infer the length of the message from that?

(This is a programming and protocol design question.)

I am not aware of any definitive, "official" answer on this subject, but this seems to be part of an attempt at genericity and coherence. In the SSL/TLS standard, all messages follow regular encoding rules, using a specific presentation language. No part of the protocol "infers" length from the record length.

One enlightening detail is the ClientKeyExchange message: in SSL 3.0, with an RSA key exchange, the contents of that handshake message are the "raw" encryption result (i.e. 256 bytes if the server uses a 2048-bit RSA key, plus the 4-byte handshake message header); in TLS 1.0 and subsequent versions, the encryption result is an "opaque vector" with an extra two-byte header containing the length, so that's 258 bytes, not 256, and still with an extra 4-byte handshake message header. This change illustrates the will of the standard designers to achieve strict regularity with as little inference from packet length as possible.

One gain of not inferring length from the outer structure is that it makes it much easier to include optional extensions afterwards. This was done with ClientHello messages, for instance.

If we look at things from a higher point of view, TLS is only half-finished. TLS, as a protocol, needs to exchange structured data; sender and receiver must be able to encode and decode such data with no ambiguity, and preferably no buffer overflow either. One strategy for that is to do the following:

Define strict, regular encoding rules for structured elements. For instance, define that every single element should be preceded by a header containing the length of the element.
Define an unambiguous language to express the structure and type of all messages as part of the protocol standard; that's the "presentation language" of the RFC.
Write a generic compiler software, into which you paste the presentation language from the RFC, and which produces an encoder/decoder implementation which handles the encoding and decoding of all messages, with systematic checks on all lengths and value ranges and so on.

An embodiment of this strategy is ASN.1. ASN.1 is used, for instance, in X.509 certificates; with an ASN.1 compiler, you could (theoretically) paste the ASN.1 syntax from the X.509 standard and obtain a complete encoder/decoder engine for X.509 certificates (I have done that, including writing my own ASN.1 compiler, and there are some "quirks", including the fact that the ASN.1 types for strings and dates appear to have been invented by a baboon on LSD; but the overall scheme still works).

Another embodiment is XML, with XML Schema as "presentation language": you push the schema and the input data into your XML parser, and if something other than an error code is produced, then you know that all the data complies with the schema, and you can walk it in a decoded, structured tree. Again, that's the theory, which is nice, as far as theories go.

The "presentation language" of TLS falls a bit short here: it does not have a compiler. That language looks like a "computer language", but it was meant for human reading. For that, it works well; however, this means that the developer will have to transcribe that language into an encoder/decoder. The developer must take care not to forget a step. And that's exactly what occurred with the "heartbleed" bug: a step was forgotten, which can have dire consequences.


How to protect against MAC spoofing in WiFi network? I have this scenario:
I want to create a WiFi network for a hotel that the customers should pay to gain access to the internet.
I tried Captive portal, but captive portal is very vulnerable against MAC spoofing.
So I tried wpa2-enterprise without Captive Portal. But NAS(Access Point) in wpa2-enterprise doesn't enforce any rule and each user had unlimited access.
Then finally I tried both together but after first authentication in wpa2-enterprise each user was able to change his/her MAC address to a any other user.
I'm using PFsense as RADIUS server and Mikrotik RB433 for Hotspot(Captive Portal) and wireless AP.

Is there any way to prevent users from impersonating to an authenticated user in WiFi network with Captive Portal?

Is there a reason that NAS in wpa2-enterprise doesn't enforce any policy or something is wrong in my configuration?
These are the policies that PFsense generated in users file:

"amir" Cleartext-Password := "amir", Simultaneous-Use := "1"

    Framed-IP-Address = 10.1.3.85,
    Framed-IP-Netmask = 255.255.255.0,
    WISPr-Bandwidth-Max-Up := 50000,
    WISPr-Bandwidth-Max-Down := 50000,
    WISPr-Redirection-URL := http://www.google.com,
    pfSense-Max-Total-Octets := 10485760,

    Exec-Program-Wait = "/bin/sh /usr/local/etc/raddb/scripts/datacounter_auth.sh amir daily"

And this is clients.conf file:
client "mik" {
    ipaddr = 10.1.2.2
    proto = udp
    secret = 'admin123'
    require_message_authenticator = no
    nas_type = other
    ### login = !root ###
    ### password = someadminpass ###
    limit {
        max_connections = 16
        lifetime = 0
        idle_timeout = 30
    }
}

You cannot prevent the user from changing their MAC address.  The MAC address is provided by the client and can be changed at any time assuming their hardware allows them to do so.  If you are relying on the client machine for implementing an effective control, you will fail because it will be able to be avoided.  Most users will not change their MAC address, but a dedicated user can do so without consequences.
In addition, captive portals are a security anti-practice.  As outlined in this article, you are basically intentionally tampering with the user's traffic to substitute your content instead of the content they wanted to see, and by any typical definition of network security, that makes you a malicious man-in-the-middle party.  In other words, you are a bad actor.  Moreover, because most sites are HTTPS with STS these days, it's very hard for a user to actually see your captive portal because their browser literally won't let them in many cases.
You should adopt a solution which doesn't rely on the security of the client and doesn't implement a MITM attack.  For example, you could have a set of randomly generated passwords, each one expiring on a different day of the week, and have the person call the front desk to add the charge to the room and get a password.  While it would be able to be shared amongst a group, it would not be any less secure than your existing approach and would be less hostile to your users.  You could additionally add a limit on the number of MAC addresses as long as you realized that a dedicated user can evade it.


Distributed md5 crack software? I'm studying about cracking password using brute force, and in my way I found softwares like John the  Ripper and MDCrack, that works really nice, but are restricted to one machine.

There is some software that I can install on my LAN PCs, and distribute the work of cracking the password? OR some software that allow use that mentioned softwares in a distributed way?

John the Ripper supports parallelization. This uses OpenMP or MPI. All of this is open source.


Should password reset link expire when clicked, or wait until reset is filled out and completed? Im implementing a password recovery solution that follows this Generic Framework convention:

https://www.owasp.org/index.php/OWASP_Periodic_Table_of_Vulnerabilities_-_Insufficient_Password_Recovery#Generic_Framework_Solution

My questions is when should the reset token be destroyed. According to the frameowrk,  "The reset token should be invalidated as soon as it is used."

Does it mean:

to destroy as soon as the user lands on the webpage to enter a new password
to destroy when we call the API to reset it with the new password

First option means the user cannot refresh/hit the page twice because is going to destroy the token in the first landing. Second option allows the user to hit the page as many times as he want because token validation is made upon a new password is provided. Although, we could go further and validate the recovery token when the customer hits the webpage but destroy it only when a new password is provided.

Can you please give me a hand on this?

Note: Link to reset password is provided by email.

I don't see a problem with #2 and it is certainly more user friendly, provided that the reset page is only available through https (so that it can't be mitm'd and someone can't sneak in faster).

I don't see a vector to exploit #2 that isn't there for #1.


Force SSL/TLS client cert authentication even if server does not request it? Usually the server specifies in the Server Hello message if a client certificate is needed/wanted.

Does anybody know if it is possible to perform an authentication via client cert if the server does not request it?

And if it possible does anybody know a client that allows to force a client certificate authentication?

The client won't send a certificate unless the server asks for it with a Certificate Request message (see the standard, section 7.4.4). If the server does not ask for a certificate, the sending of a Certificate and a CertificateVerify message from the client is likely to imply an immediate termination from the server (with an unexpected_message alert). The wording of the standard is not overly clear on that subject, but it still includes this paragraph in section 7.4:

  The handshake protocol messages are presented below in the order they
     MUST be sent; sending handshake messages in an unexpected order
     results in a fatal error.  Unneeded handshake messages can be
     omitted, however.  Note one exception to the ordering: the
     Certificate message is used twice in the handshake (from server to
     client, then from client to server), but described only in its first
     position.  The one message that is not bound by these ordering rules
     is the HelloRequest message, which can be sent at any time, but which
     SHOULD be ignored by the client if it arrives in the middle of a
     handshake.

This rather strongly suggests that an unexpected Certificate message from the client will not be ignored, and instead will "result in a fatal error".

Now you could imagine an active modification by an Man-in-the-Middle entity, who injects an extra Certificate Request message in the flow from the server, and blocks the Certificate and Certificate Verify from the client. This is possible, since the initial handshake is performed, out of necessity, with unprotected records.

However, this will make the handshake fail when the Finished messages are exchanged. These messages are protected (they occur after the switch to the newly negotiated security parameters). The contents of the Finished messages are a hash of all handshake messages sent so far. Since the client and the server did not see the same messages (from the point of view of the client, there were extra Certificate Request, Certificate and Certificate Verify messages), the hash values won't match, and the client and server will drop the connection.

So not only it is unclear what an attacker would gain by forcing a client authentication that the server did not ask for, but it will also not work at all because of the way the Finished messages are computed.


Are there risks in not having a edge firewall? I am currently working with a client that has all their external traffic going through the core switch and then is being passed to the router and back through the core switch and then to the rest of the network.

Diagram:

INTERNET -> coreswitch 10.1.1.1 ->  internal router 10.2.2.2 -> coreswitch 10.1.1.1 -> to the rest of the network.

I am trying to convince them that they should have a firewall on the outside in front of the core switch.

I feel like I am explaining basic networking or something or basic security to them because a firewall on the outside is considered to be essential in any network.

The concept is easy...think about when you travel into another country...the government inspects you (essentially) to see who you say you are and what you are planning on doing in their country. Now image if there were no customs/boarder patrol - anyone could go anywhere and could travel along pre-designed roadways & intersections (routers & switches) and you could cross boundaries like bridges (NAT) but there would be no security authority to govern what you did, where you went, and what your intents were. Basically, if you cannot inspect traffic then what good is your security?

Firewalls/UTMs (Unified Threat Management) devices are not synonymous with NAT or Routers. Yes, firewalls are security appliances & are always needed/essential at the Gateway! Their sole duty is to inspection ingress/egress traffic looking for threats and/or violations of policy. Without a firewall how would one protect against the following:

Encrypted payloads such as Ransomware, Zero-Day attacks
Rogue Services within the network such as blocking outbound DNS except for Authorized servers
Flood attacks
PoD (Ping of Death) attacks,  provided you require ping for the WAN - for monitoring, etc.
TCP State Manipulation DoS
DoS (Denial of Service)
DNS Rebinding attacks
IP Spoofing attacks
Intrusions
Malware & Spyware
Botnets attacks
Geo-IP attacks
Content-related attacks from the LAN (HTTP Proxy, Avoidance Systems)
Application behavior & control in all Zones - being able to thwart SSLv2, SSLv3, SSLv3.1/TLS1.0 traffic, stopping specific applications outside of your Authorized App Library

You need a firewall to provide inspection as a security baseline, which should include at the very, very minimum DPI (Deep Packet Inspection) & SSL-DPI (encrypted packets). Routers & switches were never designed to be security appliances with the capabilities to perform in this manner and neither was NAT.


Should BCRYPT be used for client-side password hashing I am concerned about the use of bcrypt for client-side password generation. I am developing a password generation function to be used client-side, similar to PwdHash and PasswordMaker.

Much has been said about the advantage of using bcrypt over faster hash functions because it slows down brute force attacks. I know bcrypt uses Blowfish internally, which is a symmetric encryption algorithm rather than a hash algorithm. So there must be a hard-coded key somewhere to use bcrypt, and since Blowfish is being used, it stands to reason that if the key is discovered, the password derivation can be reversed and the original password discovered.

Since client-side code can be decompiled, the key could be easily discovered, making bcrypt unsafe to use client-side. Is my reasoning correct or have I missed something?

Also, in a related question, wouldn't the same argument be valid server-side as well. A hash function cannot be reversed, but an encryption function can be if the key is known. Wouldn't it be safer to use a real hash server side, even if it is faster and therefore more susceptible to brute force attack, than to use bcrypt which is reversible?

EDIT: user10008 notes below (post has been removed) that only parts of Blowfish are used in bcrypt and gave me a link. When I followed a link I found a function prototype that includes key as the last argument. So I still see the key being used to kick-start the bcrypt algorithm. If the key is required, and bcrypt uses symmetrical encryption instead of hashing, isn't the operation reversible?

EDIT: Good answers from both martinstoeckli and user10008. I gave the answer to marginstoeckli because of the last sentence in the response:  BCrypt can be seen as encrypting with throwing away of the key. This really cleared it up for me. Basically, we go through 2 phases P -> K ; P,K -> C  and then throw away key K, leaving cyphertext C. Because we throw away the key K, we cannot decrypt back to plaintext P. Throwing away K effectively makes bcrypt a one-way function.

EDIT: From user10008, the steps I gave above are more complex, however the essence is that the key K is used in the final phase and discarded. Thanks user10008.

It's just the other way round, BCrypt does not encrypt the password with a secret key, rather it uses the password as the key to encrypt a known text. In the setup where the key is generated, it uses both salt and the password (variable EksBlowfishSetup.key), to generate a key (variable bcrypt.state) used for encryption.

bcrypt(cost, salt, input)
    state \gets EksBlowfishSetup(cost, salt, input)
    ctext \gets "OrpheanBeholderScryDoubt" //three 64-bit blocks
    repeat (64)
        ctext \gets EncryptECB(state, ctext) //encrypt using standard Blowfish in ECB mode
    return Concatenate(cost, salt, ctext)

EksBlowfishSetup(cost, salt, key)
    state \gets InitState()
    state \gets ExpandKey(state, salt, key)
    repeat (2cost)
        state \gets ExpandKey(state, 0, key)
        state \gets ExpandKey(state, 0, salt)
    return state

BCrypt can be seen as encrypting with throwing away of the key.


How to achieve interactive shell attack? Usually when a person gets a shell by attacking some vulnerabilities, what a person gets is non-interactive shell.

So when I call FTP interactive client, shell fails.

Is there any way I can do interactive stuffs without uploading some graphical remote programs - such as VNC?

Graphical shells are heavy on the bandwidth, unreasonably complex, and usually unnecessary anyway. "Shell" in an exploitation context usually refers to a text-only shell; bash or sh or zsh for example. Or cmd.exe on windows. The idea is that if you can only run one command, then the one to run is a shell, bind STDIN/STDOUT to a network interface, and then connect to it with something like telnet. Then you can type whatever commands you want.


self signed root cert can not be verified with openssl - error 18 at 0 depth lookup I'm simply trying to create a self signed cert. I created a root cert from which I created

server key + cert  and
client key + cert

While connecting to TLS server installed with server key + server cert,
client fails with message Peer's Certificate issuer is not recognized.

To debug when I want to verify my root cert itself, I get error 18 at 0 depth lookup.

http://gagravarr.org/writing/openssl-certs/errors.shtml mentions "#2 could be because certificate is self signed and not trusted" but not sure how can I verify the root certificate.

Below is my config to create root cert,

root-ca.config

[req]
default_bits = 2048
prompt = no
default_md = sha256
distinguished_name = dn

[ dn ]
C=US
ST=Seattle
L=Seattle
O=Duwamish
OU=SC
emailAddress=some.email@gmail.com
CN =localhost

cert

openssl req -newkey rsa:1024 -sha1 -keyout rootkey.pem -out rootreq.pem -config root-ca.conf
openssl x509 -req -in rootreq.pem -sha1 -signkey rootkey.pem -out rootcert.pem

Then I copied root cert to /etc/pki/tls/certs/ (Redhat os).

cp rootcert.pem /etc/pki/tls/certs/
sudo update-ca-trust extract

[root@ip-172-18-20-233 conf3]# ll /etc/pki/tls/certs
total 24
lrwxrwxrwx 1 root     root       49 Apr 17 07:59 ca-bundle.crt -> /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem
lrwxrwxrwx 1 root     root       55 Apr 17 07:59 ca-bundle.trust.crt -> /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt
-rwxr-xr-x 1 root     root      610 Feb 28  2017 make-dummy-cert
-rw-r--r-- 1 root     root     2388 Feb 28  2017 Makefile
-rwxr-xr-x 1 root     root      829 Feb 28  2017 renew-dummy-cert
-rw-r--r-- 1 ec2-user ec2-user 1688 Aug 31 22:58 restapi-root-ca.cert
-rw-r--r-- 1 root     root     1342 Sep  1 05:58 restapi-server.cert
-rw-r--r-- 1 root     root      944 Sep  1 08:00 rootcert.pem

verify

openssl verify rootcert.pem
rootcert.pem: /C=US/ST=Seattle/L=Seattle/O=Duwamish/OU=SC/emailAddress=some.email@gmail.com/CN=localhost
error 18 at 0 depth lookup:self signed certificate
OK

I'm answering to my own very newbie 101 question. I had to install root cert so that I could trust it.

I was updating redhat ca after copying my root cert to /etc/pki/tls/certs, but somehow it was not reloaded. I ended up copying the PEM manually to /etc/pki/tls/certs/ca-bundle.crt.


Is Secure Boot really Secure? I found the concept of Secure Boot quite intriguing.
I can't say that I know much about it because I don't but I believe I understand the main concept of it.

Secure Boot verifies the signature of the executable the computer is booting. (Usually, the case is the bootloader)

On a computer without secure boot, an attacker could just overwrite \EFI\Boot\bootx64.efi or \EFI\Boot\bootia32.efi depending on the architecture  with his own program, his program would somehow infect the machine OS and continue execution with Windows's bootloader which is stored in \EFI\Microsoft\Boot\bootmgr.efi

Secure Boot prevents that because the attacker's EFI executable isn't signed.

But that could easily be evaded.

An attacker could just install systemd-boot bootloader which would call the attacker's EFI file which would call the Windows Bootloader after it does its work.

Am I missing something?

systemd-boot has to be signed as well. The original signed gummiboot respects the 'secure' boot process and requires that the binaries it is to launch are signed as well:
https://www.rodsbooks.com/efi-bootloaders/secureboot.html

So it's not quite that trivial.
But there are attacks on a different part of the boot process (called Secure Boot by Windows, but not part of the UEFI Secure Boot) that do override some protections:

https://www.ghacks.net/2016/08/10/secure-boot-bypass-revealed/
http://securityaffairs.co/wordpress/50182/hacking/backdoor-keys-uefi-secure-boot.html

The very term secure in relation to x86 architecture is always relative; It has to be viewed like car crash ratings - no car is crash-proof, some just take a bit more force to make it fatal.

This is to some degree inherent to all security, but with other designs there's a steep S-curve from "open wide" to "need an an electron microscope and a focused ion beam to crack". The efforts to secure a x86+Windows system are akin to plugging every hole on a sieve to make it seaworthy - with the proviso that every plug must open automatically when some legacy feature depends on the sieve's original function of letting the water through.


Secure Hash of a very short payload - is it possible? I am looking to verify the integrity of a very small payload, approx 64 bytes, which will be stored in a QR code. I need to verify that the payload has not been generated or altered by an attacker. Adding a secure hash at the end of the payload will use up alot of my payload space. I was hoping to encrypt the entire payload with an asymmetric private key, and then attempt decryption with the public key. If decryption succeeds then the payload is assumed to be valid, and the data can be read.

Questions:

Given such a small payload, would an asymmetric key be too short, and therefore too easily hacked through a brute force attack?
Would a secure implementation of appended a hash or random padding, leave me with hardly any useable payload left for actual data?
If 64 bytes is too small, what is a realistic smallest payload size that I could use? (I want to keep the physical size of the QR code as small as possible)

Asymmetric keys are only really valuable if one of them needs to be made public (though "public" can mean different things in different contexts).

If you both generate and verify codes in private, than you can just use a private secret as part of an HMAC with a reasonable hashing algorithm.

If space is a premium, you can even get away with using the first X bytes of the resultant HMAC output, with the understanding that each byte you remove decreases your protection slightly.

If the codes need to be verified or generated in public, then first of all recognize that even a properly valid result can be subverted by some other aspect of the software chain, but ideally you can do the public part (generation of validation) using a public key and the private part using the private key.


Shared hosting is hacked My shared hosting with GoDaddy was hacked by injecting a PHP file (deade6.php) that is recreated every time I delete it. I also tried to modify the .htaccess but it gets recreated as follows:

<IfModule mod_rewrite.c>

RewriteEngine On

RewriteCond %{HTTP_USER_AGENT} google [OR]

RewriteCond %{HTTP_REFERER} google

RewriteCond %{REQUEST_URI} !

(\.js|\.css|\.png|\.jpg|\.jpeg|\.gif|\.svg|\.ttf|\.woff|\.eot)

RewriteRule ^.*$ deade6.php [L]

</IfModule>

I also found some suspicious PHP file with base64_decode and I deleted them.
But nothing works. Any idea how to remove it?

The htaccess files possibly get regenerated by the webserver when the request is made to a specific entry point. This should be a commonly used file, such as index.php.

Find and remove the relevant code from the webapp files. If you have shell access,

grep -rnw '/var/www/whatever/path-to-your-webroot' -e "deade6"

It worths having a look at /var/log/apache2/error.log and /var/log/apache2/access.log (or find an equivalent log menu at your hosting provider) as well.

Also, if nothing works, in the very final case, you can still install nginx, which ignores .htaccess, so the pages dont get the malicious php rendered while you can work on fixing the issue.


Keeping a private gpg key secret Should I really keep my private gpg key secret if it's protected by a passphrase? What if an adversary stole it? And if it didn't have a passphrase, would it be game over for me?

Update:

What to do if my private key is stolen?

Since it's easy to crack a passphrase, does it make any difference if it has or not a passphrase if and only if private key is stolen?

Looks like there's three questions here:

1)  You should keep your private GPG key secret despite its passphrase.  Your passphrase is a lot easier to crack than the private GPG key, so even having the passphrase-encrypted private key makes it potentially easier for an adversary.
What the passphrase does is apply a layer of symmetric encryption to the keyfile, so the local computer needs that passphrase to open it.

2) If an adversary stole your passphrase-encrypted keyfile, they can try to brute force the passphrase (which is far simpler than brute forcing a 2048 or 4096-bit RSA key, even with a super-complex password); or attempt a password re-use attack (check known dumps for your previous passwords).  A strong, unique passphrase could make these attacks unfeasible.

3)  If you didn't have a passphrase and that private key file was copied from you, that key would be fully compromised and someone could decrypt your previous GPG-encrypted communications (provided they had access to the encrypted copy), et cetera depending what the key was used for.  With a strong and unique passphrase, you have a second line of defense that could potentially stop such a compromise in its tracks.

In conclusion, it's always a best practice to secure your private keys with a strong, unique passphrase.    Any passphrase makes it a lot harder to compromise the private key, and one that is strong and unique might be implausible for an adversary to ever crack.


Is this code vulnerable to a CSRF attack? I am utilizing tokens to protect from a CSRF attack but to make the "back" button still work I reuse old tokens if they are set.  Does this still provide CSRF protection or can an attacker just set the "CSRFtokeneditcustomer" cookie to be somthing like "hello" and easily bypass this protection?

if(!isset($_COOKIE["CSRFtokeneditcustomer"])){
        $token = bin2hex(openssl_random_pseudo_bytes(16));//preventCSRF
        setcookie("CSRFtokeneditcustomer", $token, time() + 60 * 60 * 24,'/','',true,true);
    }else{
        $token =$_COOKIE["CSRFtokeneditcustomer"];
    }
    ?>
    <form id="editForm" method="post" action="<?= ROOT."/".$_SESSION['PAGE']['REQUEST']."/" ?>" enctype="multipart/form-data" onsubmit="return validateForm()">

<input type="hidden" name="action" value="editcustomer" />

<input type="hidden" name="add" value="1" />

<input type="hidden" name="fullload" value="<?= (($_REQUEST['fullload']) ? 1 : 0); ?>" />

<input type="hidden" name="edit" value="<?= $this->data['id']; ?>" />

<input type="hidden" name="id" id="id" value="<?= $this->data['id']; ?>" />

        <input name="CSRFtokeneditcustomer" type="hidden" value="<? echo $token?>"/>

An attacker cannot set cookies for a CSRF attack.  The only thing the attacker can do is force the victim browser to make a request to the target webserver.  Assuming you've got code server-side which is comparing the "CSRFtokeneditcustomer" field in the form and comparing it to the value in the cookie, you should be safe from CSRF.


If no one knows a password, is there a reason to change it? Scenario: A high level access account on a single machine, where the account is created by the system/application with a secure password, without exposing the password to a human or to any other machines.

No one knows or can know the password.  (Hypothetically the password could be extracted but only if the system is already compromised at the level of access the account has.)

Assume you are watching for and reporting on failed login attempts, you would know if anyone was trying to brute force the password.

The Real scenario where this occurs, the argument is presented that changing the password, could/would raise the risk.

  This leads to an argument where there is no good reason to actually change the password on a regular bases. You might want to change it on day one, if you don't trust the random password generation, but even that could add more risk then it removes, as now the password has been seen and processed with human contact.

If no one knows a password, is there a reason to change it?

Note: The example account exists as there is an alternate configuration of this solution, where the account is used to communicate between machines.  In the alternate solution the password is known by humans, and shared across devices. The current question is only about the single machine scenario.

If you believe human contact to be the ultimate security risk, then what you're saying makes sense.

But if you don't regularly change a password, then someone who was able to access the machine from an unknown vulnerability will have unlimited access to the system, forever.

Ultimately, I believe human contact to be necessary even if it's risky, maybe impose laws and bind a single senior security engineer to a contract that would put them in heaps of trouble if the password were to ever reach any sort of exposure?

( Either way, I believe it's impossible to have a no risk solution )


Is it secure to send a password recovery link for company application to an employee's personal email address? I would like to automate the recovery of the password for the employees of a company. However, the problem is that not every employee has a corporate email account and some employees can't access their corporate email, if they have forgotten their password.

Is it best practice to send a password recovery link for a company application to an employees personal email address?

Is there another method to automate the recovery of a password in this scenario?

The problem with relying on personal email accounts is that you don't have any control over how well those are managed.  How many of your employees have "abc123" as the password for their email account?  Do you want to rely on that for the security of your corporate email?

A better option would be to allow managers to reset the passwords for their employees.  Most people won't have the phone number of IT handy but they probably have their boss's number.

Let the manager set a new password and then require the employee change it on first login.

This also helps solve the identification problem.  I doubt your IT team would be able to verify all employees by voice or sight but a manager is going to recognize the people they manage every day.


JWT authentication and authorization schema I was going through Oauth2 docs and thought it was kind of permissive security wise, so i tried to implement JWT tokens with a special scheme like in the picture for a mobile app communicating with a web API.

Notes : i didnt like Oauth2 refresh tokens idea as they might get stolen and allow parallel usage (by legit and malicious users) unless you implement theft detection by rotating them (refreshing refresh token upon each request) in this case why use them at all ?

How the auth flow works :

A user logs in with credentials gets a jwt of 20 minutes lifetime.
Upon expiry the jwt gets refreshed by hitting the db checking if it's blacklisted (relogin) and if not check if it was used to generate a new token.
If it was never used to refresh it is accepted and used to issue a low grade access token.
If the token was used before, or had different client+device+user than its parent offer a credential check (password or lockscreen code)
If passed, this check issues a new first grade token that blacklists all its parents and children on the db, its like a new first user login.
If lockscreen fails the user is presented with login screen.

The questions are :

What are possible security holes ? (I found two use cases : stolen valid access token lasts 20 minutes same issue as Oauth tokens. No gain no loss here. And stolen sleeping token : user not logged in for say 7 days, token gets stolen and used until user logs in again or token chain revoqued after 3months of persistance - our policy - and this theft has small chances since token has to be intercepted at the last request the user makes on the app , slimmer than stealing an Oauth2 refresh token )
What are user experience problems an attacker can cause on the app while on this scheme ?

As @jpodwys says in his comment, HTTPS is a secure transit. It seems very unlikely to me that an attacker could steal an OAuth2 refresh token and not steal other critical information. That is, by the time you are having tokens stolen over HTTPS connections, you've already been pwned and it's game over. OAuth2 is a well-tested protocol that has many tested implementations in many languages. I strongly suspect that it will be more secure than anything that you choose to design and implement on your own. In general, rolling your own is a mistake. See all of these answers for reasons why.

In answer your question about why refresh tokens exist, they exist to allow the user to revoke authorization, not to deal with a stolen refresh token (as that effectively never happens). Consider the case where a user grants access and then later, abruptly revokes it. You want to minimize the delay between the revocation occurring to the revocation having effect. One way to bring the delay to (near) zero is by checking with the service provider on every call. But checking with the SP on every request isn't performant. Instead, you allow the access token to be used for a limited time period and force it to be renewed every once in a while. This means that if the user revokes authorization, it will take effect in a time no-longer than the life of the access token.


Relationship between FISMA and OMB Circular A-130? Can someone explain to me the relationship between FISMA and OMB Circular A-130?

OMB Circulars are instructions or information issued by the Office of Management and Budget (OMB) to federal agencies. A-130 establishes official OMB policy and guidance on information technology management for federal executive agencies.

The Federal Information Security Management Act recognized the importance of information security to the economic and national security interests of the United States. The act requires each federal agency to develop, document, and implement an agency-wide program to provide information security for the information and information systems that support the operations and assets of the agency, including those provided or managed by another agency, contractor, or other source.

Have a look on fismapedia for more info on OMB A-130.

If you look at purpose it states:

  This Circular establishes policy for the management of Federal
  information resources. OMB includes procedural and analytic guidelines
  for implementing specific aspects of these policies as appendices.

FISMA requires agency program officials, chief information officers, and inspectors general (IGs) to conduct annual reviews of the agency’s information security program and report the results to Office of Management and Budget (OMB). OMB uses this data to assist in its oversight responsibilities and to prepare this annual report to Congress on agency compliance with the act.

EDIT

To put it a bit more simple as GdD phrased it:

  FISMA is a law that says federal government agencies have to protect
  information resources. OMB A-130 says how they should go about it.


PCI DSS 3.2 SAQ-A for card-not-present mail/telephone orders (MOTO) What methods of processing payments fit into the definition of SAQ-A for orders made over the phone?

I am confused because it says SAQ-A is valid when "All processing of cardholder data is entirely outsourced to PCI DSS validated third-party service providers", yet SAQ C-VT is needed when a virtual terminal (hosted by a validated third-party) is used to take payments.

To my reading this means sticking Stripe Elements onto a page (normally valid for SAQ-A) and entering the customer's card details into it falls under SAQ C-VT.

So how could telephone orders be taken and the merchant remain under SAQ-A?

I am confused because it says SAQ-A is valid when "All processing of
  cardholder data is entirely outsourced to PCI DSS validated
  third-party service providers", yet SAQ C-VT is needed when a virtual
  terminal (hosted by a validated third-party) is used to take payments.

What differs is who takes the call.

For SAQ C-VT, the Merchant has employees who sit at a Virtual Terminal hosted by a validated Third-Party Service Provider.  Customers call the Merchant, the Merchant's employee types their card numbers into the VT, the purchase proceeds.

When SAQ A says (emphasis mine):

  SAQ A merchants confirm that, for this payment channel:

  Your company accepts only card-not-present (e-commerce or mail/telephone-order) transactions;
  All processing of cardholder data is entirely outsourced to PCI DSS validated third-party service providers;

They are describing a setup where the Merchant outsources the entire telephone-order process to a validated Third-Party Service Provider.  The Customer calls the number provided by the Merchant, but it rings at the Third-Party call center, and a Third-Party employee takes the details, enters them into the terminal, and proceeds with the purchase.

(In both cases, of course, the Third-Party is subject to much more extensive compliance requirements than either SAQ A or SAQ C-VT.  The limited scope of those two SAQs rely upon the offloading of scope to the Third-Party Service Provider).

  So how could telephone orders be taken and the merchant remain under SAQ-A?

If the phone calls go directly to the Third-Party Service Provider, and not to the Merchant, the Merchant may remain SAQ A.


Gradle daemon listens on all interfaces by default Was messing around with a project today that uses the build tool Gradle and I noticed that by default, it's running a daemon server process that listens on all interfaces.

Output of ss below.

State   Recv-Q   Send-Q           Local Address:Port        Peer Address:Port
LISTEN  0        50                           *:37367                  *:*       users:(("java",pid=25378,fd=211))

Behind the NAT of my home router, I don't have to worry about being bombarded on this open port, but when I'm on campus (where I'm assigned a public IP), Gradle will actually open connections to whoever tries to connect to that port.

Is this correct? If so, it's seems absolutely crazy to me that Gradle's default configuration would listen on all interfaces. Unless it's an extremely simple server and they're super confident it won't get expoited I guess.

Couldn't find any mention of this in their documentation.

If you are running a computer without a firewall that only allows access to approved services, then yes, anyone on your local network could connect to this service.

The developers of a service do not have to assume that their service is not vulnerable. They only need to assume that the people running their service have a minimum of security on the machine where it is run.

If something has an API, it typically exposes that API to the network in some way. This certainly was not always true, but it is the norm now. So the mention of an API is usually a clue that a service gets exposed.


Theoretical game server DDoS prevention question I may not understand how DDoS attacks work at this point, but Im just wondering if this would work for a game server?

IF each time a new connection is attempted and the packet or connection type is not similar to that of a normal player, then block the connection?

I dont see any reason for the server to allow connections that are not needed to play the game. Only 1 port would be open. The only downside I see is that the CPU would be put under a lot of stress with large attacks.

But for the most part, wouldn't this work well?

I may be completely wrong and off-base, so i'm just posting here to find out.

A DDoS attack does not necessarily saturate the network capacity, any resource which can be exhausted to result in the application being unable to serve requests can be used to achieve a DoS.

As you say:

  The only downside I see is that the CPU would be put under a lot of stress with large attacks.

The CPU is definitely a resource that can be exhausted to achieve a DoS. In the case of a game server this is probably a particularly common scenario given that the game server probably performs complex server side operations.

  not similar to that of a normal player

I suspect that determining what is not normal is another very challenging and subjective task. I imagine game developers expend considerable effort developing reasonable rate limits for computationally expensive operations to balance DoS prevention with not impacting legitimate game play. However, I doubt they get this balance right 100% of the time, just like developers aren't always able to prevent vulnerabilities and bugs 100% of the time.


Security in transferring sensitive data over web apps I am working on an app that has to transfer sensitive data over HTTPS and I have an idea but I am wondering if it is overkill or good.

One of the issues is I need the ability to "share data" between users, so I created the idea of a group.

Each user has a secret key which is stored in their browser (if they want or they can type it out everytime they want to get the data). Each users secret key is immediately encrypted upon entering it using the "code" from the server.

Each user has a "code" which is stored on the server. This is generated on registration. This is used to encrypt the secret key stored in the browser.

Each user can be part of a group, each group has a 256 bit key which is generated on created. All of the groups sensitive data are not encrypted with the users secret key, but the groups key. The each group member has the same key that’s encrypted with that users secret key. So to request group data it sends the users encrypted key to the server, the server sends back the encrypted data (encrypted with the group key AND the encrypted group key) the browser then decrypts the content by using the secret word in the browser to decrypt the group key and then uses the group key to decrypt the data.

Reasoning for all of this.

I want to make sure if the "evil person" has 2 pieces of the puzzle they are still not able to access the data. Say the "evil person" steals the users laptop which has the secret word, and possible data sent. I want to make sure they would still need to login in order to decrypt the data (to get the code which is used to decrypt the secret word). (Maybe this is excessive?)
The rest is just standard encryption stuff. With the addition of the ability to share encrypted stuff among multiple users.

Thoughts?

Ever heard of RSA?
Much more safe and much more simple.
Every client generates an private key and sends its public key to the server.
The client that starts a group generates an AES key for encrypting group files and decrypts the key with each public key of the other members. Than it sends the encrypted keys to the other members. They use their private key to open the group key. Now they all now the group secret and can exchange data secretly. 100% secure and simpler as it sounds


What is the "about:blank" context for browser security and privacy? This blog is describing a way to hide the referer header in various situations.  Specifically he is referring to things that run in the about:blank context.

What is the about:blank context?
How does about:blank, 307 redirect, and CORS relate to this? (or how would I determine this outside of the blog?)
Are there additional things that run in the about:blank context besides those listed?
Are there other security contexts that run in parallel to about:blank?

The about:blank is just a blank address-less browser screen, that will inherit the same security parameters of its caller. That said, you cannot exploit about:blank to bridge the JavaScript cross-domain access restrictions if thats what you're asking.

Despite its location is not part of your domain, it belongs to it, and will not run stuff in a different security level.


How do ERP systems track classified business activity? One of the selling points of Enterprise Resource Planning systems like SAP or Oracle E-Business Suite is their claim to give management visibility across the business, by aggregating (or at least integrating) data on different facets of business operations. Taking these claims at face value, how are ERP systems set up when a company such as a defence contractor carries out classified business?

The problem I'm imagining is that classified information could be infered from otherwise "boring" business data. For example:

HR information on job title, location, or specialist qualifications held by staff could reveal the nature of classified work being carried out.
Purchasing or Accounts Payable records could reveal sensitive subcontractor relationships or details of classified products the company develops.
Even the company's Chart of Accounts could reveal the existence and size of otherwise unacknowledged projects.

I've never had to solve this problem myself, but I can think of a few ways an ERP system could support a company's conflicting obligations to safeguard classified information and to maintain detailed records for audit and management control:

The system's built-in security features could be used to limit access to some data, while still allowing summary information to "roll up" to a safe level of aggregation (e.g. uncleared users might see a single GL account "Net classified income" with no further details). This would give cleared users or auditors an integrated view of the business, but has the disadvantage that anyone with privileged access to ERP data (system administrator, DBA etc) needs clearance.
A separate classified instance of the system could be stood up, and all classified business recorded there - effectively the time-honoured accounting practice of running two sets of books. This would require a feed of unclassified summary data to the main system, which would treat the classified instance as one more external data provider. The obvious problem here is cost and keeping the two systems' configurations in sync.
Classified data could be "hidden in plain sight", e.g. by using opaque project codes or account descriptions that don't give away sensitive information. This might work for job titles, but someone somewhere still needs to know that "Project X-123" is actually "Sharks With Frickin' Lasers" which seems to defeat the purpose of the system.

In general, how do ERP system implementations handle this situation?

Generally speaking, there is no inbuilt functionality that will facilitate this. The level of isolation required simply can't be patched into an ERP product after it is developed. SAP, particularly, is somewhat of an eldritch horror in this department.

The only effective solution I've seen used is to run a separate instance on separate infrastructure for cleared work. Anything of normal sensitivity (f.e. up to commercial in confidence) goes on the regular instance, anything secret or above goes on the cleared instance.

Of course it is often useful or necessary to have metadata about the cleared instance available on the normal instance. This can generally be facilitated by implementing a plugin on each instance for the purposes of intercommunication of that metadata, with an intermediary system that helps enforce the data contract for security purposes.

Information sharing can still be performed carefully, by installing plugins on each instance that allow for the export/import of data, and having the instance infrastructure able to communicate over only a fixed channel (e.g. HTTPS on a specific port, enforced by firewall appliance). Here's a diagram of an approach I've seen used before:

A gateway server runs a web service on a pair of ports - one for cleared-side connections, and the other for normal-side connections. It VPNs into both networks and the VPN endpoint applies firewall rules specific to that connection, allowing only inbound connections to the gateway on the correct port. The web service consists mostly of a service endpoint that validates incoming data, and a message queue that the data is placed into. Each ERP server plugin instance can connect to the gateway to send and receive messages. By combining host-based firewall rules on the gateway itself and appliance firewall rules on each side of the network, it becomes exceedingly difficult for an attacker to directly penetrate from one instance to the other.

The firewall on each side contains a rule and a route that allows the ERP instance on each side to communicate with an identity provider for user authentication purposes. This should allow only outbound connections from the ERP instance to the identity provider on the necessary port.

The VPN also allows for management connections from a whitelisted IP address range, using separate VPN credentials. For these connections a relaxed firewall rule set can be applied, but it is worth blocking new outbound connections from the instance network to the management LAN because such connections should not occur in general (and change requests can be raised if such a connection needs to happen for some reason).

The users can VPN into each instance. The blue arrow colour indicates the allowed access, i.e. the users can only access the ERP analytics front-end rather than any management features or database instances. For convenience a routing device can be placed on the user LAN which has a permanent VPN connection into the normal instance, to avoid needing VPN clients on every standard user's machine. Users who require access to the cleared instance can then VPN in separately.

You can enhance this layout in a number of ways. For example, the gateway server could have an attached log store which both instances send logs to via the web service. This means that even if an attacker compromises an instance, the logs cannot be destroyed.


When you buy a certificate, does the certificate authority have (a copy of) the private key? I always assumed that the process for getting a (trusted, not self-signed) certificate was more or less like this:

You generate a public and private key pair
From this key pair you generate a certificate
You submit your public key, certificate and other (company) information to a CA
The CA checks that the information you provided is correct
The CA signs your certificate

However, lately I am doubting this. People told me that in fact the CA itself generates the public and private key pair and certificate and signs it and sends all of that to you... This would seem to me to be very insecure in the sense that all private keys of all certificates would be in the hands of just a few CA's.

I have been reading this question with a lot of interest:
How do certification authorities store their private root keys?. However it only discusses the CA's own private keys.

So do the CA's have a copy of the private keys of the certificates they sign or not?

Depending on how the CA does things, it may or may not have a copy of your private key. Usually it doesn't.

The normal method is that you generate your private/public key pair on your own machine, then send the public key to the CA as part of a certificate request. The CA assembles and signs the certificate, and sends it back to you. Your private key never left your machine, and the CA never saw it.

However, in some cases, it is a good idea to let the CA generate the key pair, and send it to you. One situation where this is desirable is for asymmetric encryption keys: if you lose a private key, then you lose all the data which has been encrypted with the corresponding public key, since you can no longer decrypt it. Therefore, encryption private keys should be backupped somewhere, and having the CA generate the private key makes it easy for the CA to enforce a comprehensive, inescapable backup system.

To know what happens with a specific CA, have a look at what they return to you: if the CA sends to you a PFX (PKCS#12) archive, then CA has the private key, or at least had the private key (whether it saved it is another matter). On the other hand, if the CA sends to you a raw certificate only, then it does not have the private key.

In any case, the whole process should be documented by the CA with which you are doing business; if the CA does not document what it does, and in particular where private keys are generated and whether they are stored or not, then find another CA. CA which do things opaquely cannot be trusted. Indeed, it is a basic requirements of all "CA best practice guides" (e.g. Web Trust) that a CA must document everything.


Alternative way of applying authentication in network security I have been reading and thinking lately about authentication and how this is achieved in cyber security. I notice that the only way of applying authentication is through the use of cryptographic keys ( e.g. digital signature). My question is: Beside cryptographic keys, is there another mechanism that helps to distinguish the legitimate and malicious entities ?

It varies by protocol.

PAP (Password Authentication Protocol)

This is only for reference and should not be used. This is just sending a username and password in the header.

CHAP (Challenge Handshake Authentication Protocol)

Uses a challenge response method by generating a string and the client needs match it. This is more for reference as well.

Kerberos

To your point, uses secret-key cryptography to establish identity. Common, in most systems. It also provides a ticket to the user which can be used in Authorization.

NTLM

A Microsoft suite of security protocls for authentication, authorization, and integrity that uses the same concepts of challenge-response like CHAP.

Open ID

An open standard that uses the concept of decentralized authentication protocol and URLs to exchange identity information.

Explanation

Authentication is the act of proving that a user is who they say they are. Each example I provided are diffident protocols to achieve this. What I think you are miss-understanding is that Authentication as a whole is not subject to protecting prying eyes from eavesdroppers.

That is the role of other protocols such as HTTPS, which is most common and uses public key cryptography to establish a secure connection to another service.

Example

When connecting to Facebook, you uses a HTTPS connection (public keys) to establish a secure connection. You than provided your username/password, with authenticates you using if I remember correctly, their implementation of OAUTH 2.0.

The security of the connection, and the integrity of the users identity are exclusive. We tend to talk about them nominally, but they typically uses separate protocols.


Is Ed25519 still secure, despite the fault attack published in 2017? I heard that Ed25519 is a new digital signature. It has smaller public key size and generates a public key more quickly. I read an article about Ed25519 titled Practical fault attack against the Ed25519 and EdDSA signature scheme. The article mentions that the private key can be recovered in a so-called "fault attack". Knowing this, is the Ed25519 scheme still secure?

Yes, Ed25519 is still secure. The paper describes an attack against hardware processing Ed25519 signatures. It is not a cryptographic attack against the algorithm itself. As explained here, a fault attack (also called a glitching attack) involves trying to confuse a processor while it is processing cryptographic material to cause it to glitch in a way that leaks internal information sufficient to reconstruct the private key. Unless someone is hooking up electrical probes to your CPU, the attack does not affect you at all.

The attack involves hooking up a device to the CPU and "glitching" it, for example by feeding it too much or too little voltage at specific times. If the glitch occurs while cryptographic material is being processed, it is possible to discover information about the key by observing the results of the glitching. It is a very invasive procedure, as you can see in this photo of the attack being performed:

From the text describing this picture:

  We demonstrated it on an Arduino Nano, using the Arduino Libs’ Crypto Ed25519 implementation and simple voltage glitches. We were able to cause single byte random errors at the end of the computation of H(R,A,M), allowing us to efficiently brute-force the error location and value, thus recovering half of the secret key.

So why is this attack newsworthy? The answer is simply that not every use of Ed25519 occurs on a machine that you have full control over. For example, secure embedded devices, such as smart cards, might fall into adversarial hands. These devices are designed to be secure and not reveal their private key even if you have physical access to them, so it would be bad if you could steal the private key just by monitoring the device while you feed it an incorrect voltage! This attack does not mean that every use of Ed25519 is doomed to be vulnerable to a fault attack, just that each implementation must apply mitigations to avoid this issue in situations where it is relevant.


Server echoes HTTP headers back to client - any security issues with that? Im troubleshooting a server that behaves a bit odd.
If I make a request that looks like this:

GET / HTTP/1.1
Connection: close
Host: hostname
Someheader: somevalue
Location: Woot?
Set-Cookie: test=funtimes;

I will get a response with all the headers I have sent.

HTTP/1.1 200 OK
Host: hostname
Set-Cookie: test=funtimes
Content-Type: application/json
Someheader: somevalue
Location: Woot?

As you can see, headers are echoed back to the client.
I have not seen this before, and I do not think many other people have either.

Can you see any potential security issues with this kind of behavior?

There is a vulnerability called HTTP Response Splitting  that may be exploitable, depending on whether newline characters are filtered out.


Someone is using my email to create online accounts; what should I do? I suspect it’s an attempt at getting into an existing account using a leaked email/password combo. I update my passwords regularly and do not reuse, so I don’t think the attack will be successful, but it is still frustrating. Right now, I’m changing the password of the accounts created and activating two-factor authentification to make sure I keep control of accounts using my email. Then I communicate with the customer service of the different services to let them know what happened. Is this a good idea?

I’m thinking of moving on to a new email; is the hassle worth it? What else should or could I do?

Nothing much you can do. Check this very interesting chain from Google: https://support.google.com/mail/thread/6055937?hl=en

  I have tried working with them, but they claim they were able to register the email, with the identical name (no dot). As this "bug " is now sharing that person's PII with me, and Google is located in California, I would think they would want to resolve this issue. However, there is no way listed of speaking/contacting someone at Google to resolve this.

Claim, being the keyword here. You will see this is a recurring pattern of phishing information. People will contact the other side, which claims that they get the same emails and when you ask them to forward one then communications stop.

Not much point changing emails, it can happen for any addresses, like other spam does. The bothersome thing is that those emails get through your provider's filters whereas spam doesn't.

My suggestion is to whitelist addresses for your account instead of blacklisting. This way only certain people can get to your inbox and when you want to register, you can always access your junk mail and add this new domain to your whitelist.


What are the problems with users sharing network passwords? I have just taken control of a small corporate network with aprox 50 users. They have no firewall, no internet monitoring, thankfully they do have AD set up.... Anyway its just the way its grown up over the last 5 or so years with little-to-no proper IT intervention. it sort of works, but its time to sort it out.

So it has become clear that people are sharing user accounts, using other peoples' accounts, and certainly one team even has a list of their passwords on the desk, as they never change and sometimes need to "nip on" to someone else's account...

My recent background is in slightly bigger networks, say 500-1000 users, where strict IT policies are enforced, passwords are changed by force monthly, and everyone has their own account, passwords are NOT shared.

This needs to change - but i will likely get resistance from the management and teams. So, What reasons can i give to the management to justify the "crackdown" and enforcement of a stricter IT policy?

The reason behind not having shared passwords should be pretty simple. If you are able to record network activity and log Jane does X illegal activity on the network, well if everyone know's Jane's password, you can't attribute the activity to Jane. You'd be hard pressed to prove in court that she committed the act as everyone could have logged in as Jane and acted with her account. It's a legal issue mostly, which should be pretty easy to sell to management.

So if you know your manager's password you can log in as your manager, do whatever illegal activity you want, and now your manager could potentially be fired because someone above him thinks he was doing things he shouldn't have been doing and ultimately didn't actually do, but it sure looked like he did.


What are the advantages of sequential signing What the advantage of sequentialy signing a document? That means signing a document by two people in a sequential manner?

If by "sequential signing" you mean "signing the encoded signature of someone (computed over a given document)", then this can be viewed as a kind of "countersignature", meant as a formal approval in a multi-layered hierarchy. E.g. some employee signs a purchase contract but it must also be approved by his chief.

CMS contains a format for that (section 11.4 in RFC 5652). However, CMS does that only on the "raw" encoded signature, without the original document or even any indication of which signature algorithm was actually used in the first place; this opens the road to a variety of tricks which make the actual semantics of CMS countersignatures a bit hard to nail down. For instance, it is possible, given an arbitrary bit string, to create an asymmetric key pair for which the bit string becomes a valid signature over an arbitrary document; so not only does the countersignature not prove that the countersigner saw the original document, but it is also possible that the countersigner saw another document and another public key for which the signature looked valid.


How to use encrypted internal strings and config? I was reading the CIA leaked documents on wikileaks, I saw in their "best practices" section that it was advised to encrypt all strings and config information and to de-crypt in memory when needed.

I was wondering how this works. I understand how to on the fly decrypt and the rationale behind having config strings in your program encrypted; so that anyone trying to reverse engineer the program cant see any meaningful strings.

But how do you store the key? if this is an autonomous virus, the key to decrypt those strings and config data has to be also stored in the program? how do you store the key so that the program can use it, but a reverse engineer will not find it?

Unless of course I have misunderstood the type of program that would employ this practice.

You are right that the key will always have to be availabe to the program that uses on-the-fly decryption of some of it's parts. There is no way around that, which means that this is the kind of security that protects you against your little sister, but not against a determined attacker (paraphrasing Schneier here). It's impossible to keep a capable attacker from finding the key.

For viruses, encryption is useful for another reason: Virus scanners scan for specific patterns, and if you encrpyt large parts of the virus, using randomly generated keys, much of the pattern matching becomes useless. The only thing left to match against is often the initialization code and the decryption function, and there are tricks to change the binary fingerprint of these parts, as well.

The way this could work is that when a virus infects a new system, it creates a copy of itself, but uses a different encryption key and shuffles around various parts of the decryption function and init code, so the copied virus doesn't look like the original at all.

What you read might be related to that: If you encrypt config strings, it becomes much harder to simply grep for a string to detect a specific program. But it's hard to tell without a reference to the document you mention.


What metrics are available on malware? All the main AV have a risk rating or severity level, how do they determine what is "low","high",etc.?

Each company will use a different scale, but they all will likely be the result of a weighted score considering:

if it escalates itself
the damage it causes
if it disrupts communication
how hard it is to block/remove
how easy it is to get infected
how it gets passed on to other machines

Here is a similar scale:
http://reviews.cnet.com/4520-6600_7-6274750-1.html

Symantec rates malware based on reputation and behavior classification and doesn't use a 'low-high' scale anymore.


Access to raw html source code after angular client side processing I need help to check if parameters are sensitive to XSS injections in a webpage generated by angularjs.

Today, many websites are using angularjs in order to deport client page construction at the client side (so this work has not to be performed at server side anymore).

So, when I perform a HTTP request, the server answers with a source code which is a template for angular to construct the page. So, this server answer is not corresponding to the final webpage that I can see after angular processing.

by using CTRL+U (show source code), this is the same problem, I will only see the answer of the server (before angular processing).

By using firebug or web developer console, I can only see a kind of "render" of the raw source code.
For example, if a try to inject aaaaaa

Finally, I have found that if I make a right click and "copy html" (chrome) or "edit" firefox. I can see the raw source code which show me what is actually escaped:

aaaaaa&lt;script&gt;alert(1);&lt;/script&gt;aaaaaa

For the little story, I have found this by wanting to copy the extract of code in a comment on security.stackexchange.com ^^

You can use Chrome's Inspector to view the DOM tree as HTML. There you see the rendered result of the AngularJS processing.

But provided that you use AngularJS correctly, it takes care of all escaping and won't allow any XSS vulnerabilities (otherwise they are vulnerabilities in AngularJS itself).
You need to use $sce and ng-bind-html to make AngularJS insert random HTML unsanitized into the document.


Create certificate without private key with OpenSSL I know that OpenSSL requires the CSR to be signed for a reason: to assure CSR validity, the fact that it was requested by the actual private key owner of the attached public key. It is absolutely fine, but in theory a CA can assure validity in other ways, especially when the CSR is never in transit. This is the case with self signed certificates, e.g. with locally issued and used company certs. In my case I would like to create certs without the private keys because they are generated on smart cards and they cannot be exported ever. And no, cards do not generate CSR during key generation.

I have not found any option in OpenSSL create a certificate from the sole public key. Despite in theory it is very well possible.

Is there an option in OpenSSL to do so? Any other means?
I need to create X509 certificates.

Thanks

As AJ Henderson suggested, the perfect solution would be to have the OpenPGP card sign the CSR. It turned out that is possible with the gpgsm CLI tool. Damien Goutte-Gattat from the GnuPG-user mailing list answered the question:

    Is there any way to create an X509 CSR signed with the private key stored on
    the card?

  Yes, you can use the gpgsm(1) tool for that.

  Make sure your card is in the card reader, then:

 $ gpgsm --armor --output mycsr.pem --gen-key

  You’ll be prompted to select what kind of key you want, choose
  "Existing key from card" (make sure your card is in the reader).
  Then select which  of the card keys you want to use (the signing key,
  the encryption key,  or the authentication key) and the intended use
  of the future certificate.

  At the end of the procedure, you’ll be prompted for your PIN in order
  to  sign the CSR.

  The documentation of Scute has a complete example (it uses
  gpgsm-gencert.sh, a deprecated helper script, instead of the above
  command, but the procedure is almost the same).

So there is no need to circumvent the CSR, you can make a valid X509 cert with GnuPG.


Questions about in-scope information assets for an ISO27001 ISMS I am in the process of writing a Scope for the information assets - in preparation for writing an ISO27001 compliant ISMS.   I am confused as to if a VPN network is considered to be in Scope? as well as things like the Wireless access point for clients?

The word information asset is confusing to me. Any information that is critical to the business is considered an information asset.  Does this include controls to get to such information. If there was a Switch connecting all of the employee work stations together - would this switch need to be in scope or not?

Many thanks for your help in this matter.  Having read all document online regarding this the scope is the most important part of the document.

An asset is whatever your company considers that have value for its business. Information asset is every asset related to information, that in theory, could be anything from people, technology, physical sites, devices, documents, etc.

Choosing a correct scope for ISO 27001 can be difficult. If you broaden it too much, it will be difficult to implement the standard. If you narrow it too much, you will let important things out and it also could be difficult to implement due to interfaces management.

My advice is to consider out of the scope only things that are:

Not related to your core business
Not related to the objectives of the ISMS or the information that your organizatio would like to manage under the ISMS
Independent of the assets that are in the scope

For example, the VPN you mention. It is completely independent of the processes of your company that are in the scope? If the VPN is used by people in the scope or it opens connection to a network where data in scope is transmited, it is in scope.

A wifi access? The same, probably is in scope.

For example, if you have multiple offices and one of them does only administrative tasks that are not in the scope and its network is isolated (completely independent) from the rest of the company, you can put this office and its technology out of the scope.

Remember that if you put some part of your company out of the scope, you have to identify the interfaces (communication of information between the parts in scope and out scope) and apply additional security controls there to protect that information going to a less secure zone. That can increase the complexity of ISO 27001 implementation and thus sometimes it is easier to broaden the scope that to narrow it.

If you have doubts, it is better to broaden the scope.

Another very related question and maybe is your problem is which granularity choose when doing the inventory of information assets? Do I have to write down the number of pencils as them can be considered information assets? Mouses? Monitors? Faxes? I'm sorry, there are no definitive answer to this question. The organization has to choose how deep it wants to go with the inventory. The assets in the inventory have to be important for the organization and the inventory have to be manageable to be updated properly.


SSL benchmarking For Openssl I have client and server code for different SSL implementations like, openssl, wolf ssl, matrix ssl and I want to benchmark these implementation based on:

Influence of symmetric key generation frequency.
Influence of CPU performance.
Influence of the asymmetric key size.
Influence of the object size
Influence of the cipher

How can I proceed? which tools will be helpful?
And also see this link
 BENCHMARKING SSL PERFORMANCE  :

This kind of output is needed but i dont know what tool is used by them.

I suggest that you take a look at the results and procedures listed here

Copied verbatim:

Install openssl-utils (with its depencies this will require about 790KiB of storage)

opkg install openssl-util

Then run:

openssl speed md5 sha1 sha256 sha512 des des-ede3 aes-128-cbc aes-192-cbc aes-256-cbc rsa2048 dsa2048 | tee /tmp/sslspeed

echo "|" `awk 'match($0,/r[0-9]+/) {print substr($0,RSTART,RLENGTH)}' /etc/banner` `awk -v FS=": " -v ORS="" '/(Processor|BogoMIPS|Hardware|machine|cpu model|system type)/ { print "| " $2 " " } END { print "" }' /proc/cpuinfo` `awk -v ORS="" '$1 ~ /OpenSSL/ {print "| " $2 " |"} $1 ~ /(md5|sha)/ {print "  " $5 " |"} $1 ~ /(des|aes)/ {b = b "  " $6 " |"} $1 ~ /(rsa|dsa)/ {print b "  " $6 " | " $7 " ";b=""} END { print "|" }' /tmp/sslspeed | sed 's/\.\(..\)k/\10/g'`

echo


Why was LibreSSL PRNG unsafe on Linux? From the article LibreSSL's PRNG is Unsafe on Linux.

The first version of LibreSSL portable, 2.0.0, was released a few days ago (followed soon after by 2.0.1). Despite the 2.0.x version numbers, these are only preview releases and shouldn't be used in production yet, but have been released to solicit testing and feedback. After testing and examining the codebase, my feedback is that the LibreSSL PRNG is not robust on Linux and is less safe than the OpenSSL PRNG that it replaced.
Consider a test program, fork_rand. When linked with OpenSSL, two different calls to RAND_bytes return different data, as expected:
$ cc -o fork_rand fork_rand.c -lcrypto $ ./fork_rand Grandparent (PID = 2735) random bytes = f05a5e107f5ec880adaeead26cfff164e778bab8e5a44bdf521e1445a5758595 Grandchild (PID = 2735) random bytes = 03688e9834f1c020765c8c5ed2e7a50cdd324648ca36652523d1d71ec06199de

When the same program is linked with LibreSSL, two different calls to RAND_bytes return the same data, which is a catastrophic failure of the PRNG:
$ cc -o fork_rand fork_rand.c libressl-2.0.1/crypto/.libs/libcrypto.a -lrt $ ./fork_rand Grandparent (PID = 2728) random bytes = f5093dc49bc9527d6d8c3864be364368780ae1ed190ca0798bf2d39ced29b88c Grandchild (PID = 2728) random bytes = f5093dc49bc9527d6d8c3864be364368780ae1ed190ca0798bf2d39ced29b88c

And:

Unfortunately, when I suggested the second change on Hacker News, a LibreSSL developer replied:

The presence or need for a [RAND_poll] function should be considered a serious design flaw.

Question: Is this bug a design flaw in Linux or was this an error that the LibreSSL devs made?

Philosophical differences.  LibreSSL is designed under the philosophy that an SSL library should be an SSL library, and nothing more.  This means it doesn't try to implement half of libc, or provide other OS-level facilities, and it should not compensate for flaws in the OS -- the OS should be fixed instead.  A pool of high-quality entropy is one of those facilities that the OS should provide.

That said, describing RAND_bytes as "unsafe" is overstating things.  It's only unsafe under Linux under very limited conditions:

The program uses the old-fashioned fork/exec model of threading, rather than the newer pthreads model.
The program must have a structure where a grandparent process forks a parent process and exits, then the parent process forks a child process that, by chance, gets the same PID as the grandparent.  This is, to put it mildly, a highly unusual program structure.
The grandparent and grandchild processes both use LibreSSL's PRNG, while the process in between them does not.  This is again a highly unusual program structure, as a typical program will either perform SSL operations exclusively in the grandparent (connection-handling process with a group of worker threads) or in the grandchildren (process manager with a group of connection-handling threads).


Why do we want a timeout on a server? This question is quite general as I want to understand the (security) benefits of a 'timeout' in general.

For our Nginx proxy-server, we have been using HTTP/S timeouts where we came across the issue were the Nginx server returned a time-out. Now, we have solved this by simply increasing the Nginx time-out. We keep upscaling the timeout, may it be for a specific endpoint, it seems we keep pushing an underlying problem. We see this problem again and again where I asked the question: Why do we even want to have timeouts?

Thinking about some malicious attempts, like sending a bulk of load to the server, if Nginx gives a timeout (or any 'timeout manager') the server would still be processing the data.

So, why would we use server timeouts and what would be a better way to solve the issues for reaching the timeout cap every time? Would be paradigm like WebSocket, SSE or (Long-)Polling resolve this?

Timeouts are necessary because the internet is unreliable.

We like to think of the internet as based on "connections", but that's not actually true. It's based on individual packets, which are received discretely and independently of each other.

In simple terms, when the server wants to send or receive data, the server usually can't send all the data in one packet. Instead, the data is chopped up and sent in individual packets.

In the best case scenario, the client would receive each packet, and then send an acknowledgement back that the packet was received. But what if the client never responds? This can have various reasons such as bad internet connectivity (think mobile internet), a crashed application, someone tripping over a cable, the bomb detonating on bomb site B, etc...

The server is blissfully unaware of the fate of the client. All the server knows is that no acknowledgement was received, and assumes the packet was lost, so the server sends the packet again. If the reason why the packet was received was temporary, then the client will receive the resent packet without problems and the communication will continue. If the reason is more permanent, you don't want the server to keep sending packets needlessly if the client would never answer.

As a result, the server at some point "times out", assumes the client is gone and frees the resources it has allocated for the transmission.

Why is this relevant for security?

The Slowloris Attack abuses the way how many web servers treat incoming connections. By sending requests veeeeeeeeryyyyy slooooooowly, the web server never quite times out, but instead has to keep allocating resources to keep the incoming request in memory.

The solution, or rather, mitigation to these attacks is limiting how slow a client is allowed to be. By sending them a timeout if the request took too long to complete you effectively set an upper bound on how effective such an attack can be.

What about clients just sending lots of data?

You can configure the server to set a maximum request size. Anything larger than this would be disregarded and the connection would be reset mid-transfer.


Online challenge: Are there any known attack vectors given the following TLS setup? I'm trying to solve an online challenge and I've hit a wall.
We're given the address of a web server with two endpoints:

One endpoint accepts a CSR and a private key and returns a
certificate signed by the server's SSL certificate if, and only if,
the CN specified in the CSR is not "administrator". The server's
certificate is self signed.
The other endpoint implements TLS 1.2 and asks for a client
certificate that has the 'Distinguished Name` set to the server's
organization name (I've picked that up from Wireshark).

After the connection is established, the server returns either a regular page for non-administrators, or a special page (which contains information I'm supposed to steal) for the administrator.

The only idea I've had so far was to generate two certificates:

One will be used as the CA and will have the DN set to the server's organization name
The other will have the CN set to "administrator" and will be signed by the first certificate.
While the browser did offer to use that certificate while handshaking, a general TLS connection error followed immediately after.

Are there any known attack vectors against this setup that I should get myself familiar with?

One endpoint accepts a CSR and a private key

end of story. Client shall never expose their private key to anyone. Private key is known only to its owner.

  returns a certificate signed by the server's SSL certificate

only CA certificates are allowed to sign other certificates. SSL and other client-type certificates are not allowed to sign other certificates. CA and end-entity certificates are distingushed by Basic Constraints certificate extension. If isCA attribute is set to True, the certificate is CA certificate and can be used to sign other certificates, otherwise it is end-entity certificate and cannot be used to sign other certificates.

  if, and only if, the CN specified in the CSR is not "administrator"

there must be additional client authentication mechanism to determine if particular requester is authorized to get signed certificates from your CA (of course, if you have CA). Otherwise, any user can submit request on behalf of other users (non-administrators) and impersonate them. Ultimately, you need to authenticate and authorize every requester and sign certificate only when CSR contains names allowed for authenticated requester. Otherwise, CSR must be rejected.

  The other endpoint implements TLS 1.2 and asks for a client certificate that has the 'Distinguished Name` set to the server's organization name

this sentence is a bit unclear. What's the point of this requirement? If you want to allow client certificates signed by your CAs, it is better to use a CA whitelist in client certificate validation logic. That is, client certificate is accepted only when it is issued by an explicitly approved CA.


Prevention measures against laptop seizure at US borders Since laptop and other electronic device seizures at US borders became legal without a warrant (including making copies of data), 7% of ACTE's business travelers reported being subject to a seizure as far back as February 2008.

What measures have IT departments taken since to protect sensitive corporate data, and are there any estimates of their (aggregate or individual) costs? I've only found this article about the economic costs of laptop seizure, but no figures are mentioned.

The ANSSI, French government service in charge of IT security, has published a document providing brief advice to people having to travel abroad.

Relevant here are the advisories concerning preparation before travel:

Review the applicable company policy,
Review destination country applicable laws,
Prefer to use devices dedicated to travel (computers, smartphones, external storage etc.) and not containing any data not strictly needed for the mission,
Backup all of your data before leaving and keep the backup in a safe place,
Avoid taking any sensitive data at all, prefer to use a VPN (or a specially set up secured mailbox where all data will be deleted after retrieval) to retrieve the data securely (this is one of the most on-topic pieces of advice, since this one prevents any sensitive data from being present on the computer when crossing the border),
Use a screen filter to avoid shoulder surfing during travel,
Apply a distinctive sign on the computer and accessories (like a sticker, do not forget to put one on the computer bag) to facilitate tracking and avoid any accidental exchange.

The linked document then goes on with other advice concerning the rest of the trip but this is less relevant regarding the current topic. Sorry to provide French documents as a source, but the ANSSI is an authoritative source in France and I felt it could be a worthy addition to this discussion since these advisories seem to properly address the question.

Edit:

As some comments and the very useful answer from Spehro Pefhany below pointed out, there are two other things which should be noted:

If your computer is seized, if you are requested ciphering keys and password, do not put up any resistance since it may lead you into legal trouble (I suppose you are traveling with some sort of mission, it would be too bad for the mission to be canceled because you were not in measure to attend the meeting or respect some contractual engagements. Customs may have plenty of time, you may not.) However, immediately inform your company IT staff and managers so due actions can be taken (revoking corresponding accesses, passwords, certificates, etc.) and discuss the issue with them to determine the way to proceed since the seized then returned devices may not be trustable anymore (impact and mitigation directly depends on the nature of the mission).
Customs are a two way passage. When preparing your luggage for the return travel, ensure that you have properly cleaned up you devices (again, not only the laptop: all devices including cellphones, external storage, etc.): send your data to your company (in a ciphered form, again either using a VPN or a secured one-time email account) then wipe the files using appropriate software, delete browser's history/cache/cookies, delete OS temporary files, delete call, messages and voicemail history, delete information about used networks (Wifi accesses, proxies, etc.).

And while I'm at it, good advice for the traveler:

Be careful when you are offered any external media like a USB key or a CD. Be careful too when exchanging documents with other people using writeable external media (as a reminder, the write protection on SD-cards is software only and therefore cannot be trusted),
Do not plug your cellphone into the free public USB chargers, which are becoming more and more frequent in places like airports,
No matter if your devices have been seized or not, do not plug them back on your company network unless they got at the very least a thorough check.
At your return change all passwords which were used during your travel.