Tag Info

Hot answers tagged

8

It is generally suggested that CSRF tokens are applied to login forms to prevent session donation attacks. The idea is that you can trick a user into visiting a link, and they become logged in under an account that you control. They then perform some action involving storing some secret information to the account, without noticing they're logged in as you, ...


7

Secure Communication The communication protocol must be secure. If the communication channel is insecure then the authentication is insecure. TLS/SSL is one way to secure the communication protocol. If you don't use TLS/SSL you would need to build a framework to build a secure communication protocol over an insecure link. If done properly ...


6

Before the attacker can send any data to the SSH server, he has to complete a TCP handshake. This means the attacker has to guess a 32 bit sequence number. (If SYN cookies are used, the attacker's chances may improve.) Assuming your server is generating good sequence numbers, this will significantly reduce an attackers ability to attack your SSH server ...


5

In short no. Because SSH runs on TCP (although there is a UDP version, this is unusual) a TCP handshake is required to commence the SSH protocol's own authentication and its following communication. A private address will not cross your perimeter router to and from the public internet so any spoofing of an internal address as it comes inbound (assuming no ...


4

Ensuring a file is the right file type is challenging, and sometimes impossible. When possible, use a strict file parser. For a PDF file, use a pdf library or pdf parser to parse the file and reject the file if any parsing issues arise. This can often have real compatibility consequences, since many PDF clients allow malformed PDF documents. Save the ...


4

I'm wondering why AJAX is not used to log in nor register in most of the pages and it's used PHP reloading the whole page. Is it about security, or it's just that it's not practical at all? Ajax is not a special thing regarding the transport of the login data, because it is a HTTP request done in the background instead of the foreground. Thus if done ...


3

They fixed it when they implemented transport layer security, it provides end-to-end encryption (and authentication) between the browser and the webserver. So, even though a "hacker" could intercept your traffic, it will be encrypted and stealing your credentials is a lot harder. If the "bank site" doesn't use transport layer security, then that's a very ...


3

When the credentials are wrong, the server sends you back a page containing the filled username and perhaps also the password. That should be done with https, and caching headers asking not to store it, but there's the possibility that the error page that was sent with the provided password in the source is stored somewhere (browser cache, an intermediate ...


3

There are a few ways to do this. You can come down to the following statement: For authentication you can only use something the user knows, has or is. As you're in a file-encryption scenario, this should rule out most points concerning "what a user is", because they involve biometrical data, which needs to have tolerances. A password or passphrase. ...


3

The scenario you described, wherein, the login form doesn't not include a CSRF token may give rise to the situation where an attacker uses his own credentials to log the victim into the attacker's account and if the user is oblivious to which account he is logged in to, the attacker can see what actions the victim performed including as suggested above, any ...


2

You are missing some points. If someone steals a copy of your Password Safe database file they will not be able to unlock it unless they also have physical possession of your yubikey (Even if they already know what your Pass Phrase is). Of course, if an attacker has a level of access to your system where they can read memory then you are screwed as soon ...


2

Currently, the YubiKey can be setup by the user during configuration so that it is write protected. This is so the device cannot be compromised by some sort of malicious script being loaded onto it, it's also to prevent the integrity of the key being compromised as well. Although, if someone has the physical device, then really there is no need to go any ...


2

The key in a TLS certificate is for a public-key cryptosystem. This is because the same key is sent to every client, and sending out a secret key to anyone who asks is not considered a viable security strategy by most experts. The reason the certificate is signed with a public-key algorithm is that there's otherwise nothing stopping an attacker from ...


2

Obligatory disclaimer: If at all possible, don't implement your own crypto. Verifying the validity of the decrypted file first and then decrypting it regardless of whether the MAC matches is the most secure way of doing this. After this, make sure that if any error occurs the same kind of error is always returned. Disclosing any information on the reason ...


2

As with any two-factor authentication (2FA) method, then you're back to essentially only having a password protecting your account. But with grids I'd consider the printout a greater security risk than the server getting hacked. The thing that I find hilarious about grids as a 2FA method is that A) they are too complex to memorize, so you HAVE to have a ...


1

For static/fixed ECDH or static DH, like plain-RSA (akRSA), server proof-of-possession is implicit by having keyexchange correctly produce Finished. OpenSSL apparently indicates this by using the KX algorithm for the Au= algorithm, since there isn't really a specific algorithm used for authentication. Note OpenSSL implements static (non-EC) DH only very ...


1

Taken from RFC4492 Section 2.1 2.1. ECDH_ECDSA In ECDH_ECDSA, the server's certificate MUST contain an ECDH-capable public key and be signed with ECDSA. A ServerKeyExchange MUST NOT be sent (the server's certificate contains all the necessary keying information required by the client to arrive at the premaster secret). ...


1

00 is the telephone prefix to dial international numbers in many countries, including the UK. The 1 to 3 digits that follow 00 are a country calling code, in this case the code is 800 which is an international toll-free number. As far as I know, 00800 numbers are always toll-free, so this can't be a scam where you are tricked into calling an expensive ...


1

When attempting a login and entering the wrong password, I would state that there is no reasonable reason to keep the password entered - the user can't see the characters, and thus can't see any mistake they may have made, nor correct it, so they'd have to start over anyway. Additionally, there is a reasonable reason to not store invalid passwords for any ...


1

There isn't so much a disadvantage of using javascript to hash the password, but there is little advantage. This does provide protection against a passive capture, but doesn't offer any more security over SSL. Attacker has an Active MiTM or has control of server In the case the attacker can Man in The Middle a connection between client and server, the ...


1

Basically what you added is like an old fashioned, physical "key" to your password storage. A "key" that no locksmith can duplicate. In your existing model the "passphrase" was the weak link. If you accidentally disclosed it, or someone shoulder surfed, or recorded your keystrokes, or you reuse it on an iffy website an attacker could get into your ...


1

Assuming this is all done during the enroll process, which it sounds like it is, there isn't a lot of risk associated with displaying the plaintext answers to the user. It's pretty unlikely that an attacker will be able to hijack a user's session mid-enrollment in order to see the security question answers. However, it doesn't seem like it would be ...


1

If your intended goal is to stop man in the middle attacks then it sort of works in theory, but practically speaking it falls apart fairly easily. This is just what I see as obvious. I'm sure there are more things I've missed. You're relying on the secrecy of the password to protect the entire conversation, which means its effectively a symmetric key. ...


1

I think you cannot authenticate the client using mutual SSL/TLS handshake with GAE. To achieve this in Java EE you should put this into web.xml <login-config> <auth-method>CLIENT-CERT</auth-method> </login-config> Source: https://docs.oracle.com/javaee/6/tutorial/doc/glien.html However, AppEngine docs says: App Engine ...


1

The API-SECRET as the name implies is secret and therefore should never be revealed in the client-side (nor on mobile applications). This credential is being used for generating signatures which can then be used for listing, deleting, overwriting and editing your content. You should either store it on the server side and pass only the generated signature, ...


1

You need a client certificate for each user (or client app if your app is authenticating to the server) that will use mutual auth SSL. You can purchase client certs from an existing CA or create a self-signed CA cert and issue your own certs. If you have many users, purchasing certs can be expensive.


1

The server certificate and the CA certificate used for authenticating your clients are two different things. First, you need to have your server certificate installed (SSLCertificateFile and SSLCertificateFileKey). You should already have that. At this point, you have your server presenting his certificate to clients. Now, you need to generate a CA ...


1

In your scheme, you are substituting the password by it's hash. The hash becomes the password. An attacker who is able to sniff the hash can authenticate to your server with it without knowing the password. The attacker just has to craft a correct HTTP request and send it to your server, or edit the javascript of your login webpage in his own browser to ...


1

The source code of password Safe is open source so you're free to do what I did: check. A HMAC takes two inputs: the key and the data. What PS does wirth the ubikey is take your input as data and send it to the UbiKey. The key is in the UbiKey itself ans stays there. So, the sequence of event is the following: You enter your passphrase. The software ...


1

For a typical email activation it should be okay, however for a password reset or an email confirmation which logs you in afterwards you usually want to ensure tokens are single use. That ensures that a man-in-the-middle logging requests (ie. a corporate network administrator) can't follow the same link and log in after the legitimate user. Your expiry ...



Only top voted, non community-wiki answers of a minimum length are eligible