Tag Info

New answers tagged

0

There still are two risks even with good password strenght and good access control in the office. Even if Team Viewer pays high attention to security, there is still a possibility of the programm being compromised, as in remotely exploitable by some kind of vulnerability. PC's staying on in the week-end would allow an attacker to freely use the exploit ...


1

The answer is yes, it is possible. However, there are some significant limitations. Through the use of IP spoofing, it could be possible to establish a connection which could be used to deliver a payload to the target, but it will not be possible to establish a true bi-directional TCP connection. In simple terms, the attacker can get the target machine to ...


0

This is bad password policy by most standards, but here is the oldest issue (or excuse) in the book (at least for Canadian banks): Security vs Convenience The banks do not see the lost a important as user convenience. The fact is that they are not losing enough money due to hacking (at least yet) to consider hindering the user experience. ...


1

The method you propose is actually what is used by some IC card formats including Sony's FeliCa: FeliCa's encryption key is dynamically generated each time mutual authentication is performed, preventing fraud such as impersonation. (From Wikipedia) This could be implemented simply by hashing the card ID (or other unique data) and the last system ...


1

Make the external site a SAML 2.0 Service Provider (SP). Set up an internal SAML 2.0 Identity Provider (IdP) to authenticate the corporate users with SAML 2.0 ADFS. Use SP initiated SSO and have the external site configured to hand off to your IdP with HTTP-POST. The IdP can be configured to authenticate a user logged into your ActiveDirectory domain with ...


1

It is not currently possible to bruteforce an SSH connection using only keys-based authentication. A VPN on top of an SSH connection does not therefore add substantial security. It would be better to concentrate on reducing the collateral effects of bruteforce attacks on your SSH connection (DoS and logs trashing would be the top ones), which is described ...


1

SSH and VPN provides basically the same encryption mechanisms. Let’s imagine they both provide the same security, and you configured them well. If an attacker is able to decrypt your VPN communication in a reasonable time, it probably means that he can do the same thing for SSH in roughly the same time. So, you did doubled your defence, but at a relatively ...


1

I have used RADIUS to authenticate VPN users (both OpenVPN and Cisco in two different set ups) and it worked very well. There is a lot of other uses for RADIUS.


0

Adding ASP.NET Identity should not be that big of a job. Guide here. Session has not been designed as an authorisation mechanism. It has some characteristics that make it unsuitable such as using the same identifier pre and post authentication, making it vulnerable to session fixation. Also, it is difficult to check authorisation status for page access, as ...


0

No.. it is extremely insecure to allow the user to create an UserId of his choice. As it will allow the user to check the userids which are existing just like the email creation. As an example, if user tried to create an userid like "stackoverflow" it will not allow to create if it is already existing. This will user will not userid of atleast one customer. ...


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 ...


1

Since both implementations rely on the security of the cookie to protect the session, that means the comparison mostly relies on the qualities of the cookie values (meaning if you steal either cookie you're in). Both values are basically a value encrypted against a key stored server-side. Sessions uses a random value encrypted against the machine key, and ...


0

A Virtual Private Network on an end-user device (a PC for instance) is just that: a network which comes in addition to the ones you already have and which binds your client to a remote server/network though an encrypted tunnel. It is set up after having received the authorization to do so in some way. This is usually bundled with the server/client solution ...


4

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 ...


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 ...


0

The question is not if it's "as safe as" traditional password: it's not meant to achieve the same thing. For telegram, a "user" is a phone number: anyone having access to that phone number is, by definition, an authorized user. In other words, it delegates the security of you account to you and your phone company.


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). ...


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 ...


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 ...


0

In Session-based Authentication the Server does all the heavy lifting server-side. Broadly speaking a client authenticates with its credentials and receives a session_id (which can be stored in a cookie) and attaches this to every subsequent outgoing request. So this could be considered a "token" as it is the equivalent of a set of credentials. There is ...


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 ...


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 ...


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 ...


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 ...


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. ...


0

The quick answer is that storing the plaintext authorization tokens in a database is not a problem but there are some other aspects that are more critical in keeping the tokens (and use of them) safe. Make sure the oauth_consumer_key (app key) and oauth_token (authorization token) are never sent to or stored at the clients side (the users browser, phone, ...


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 ...


0

What would be a disadvantage to this approach compared to standard approach with transmitting plaintext password over the internet and then hashing and storing it on the server? Users who use multiple computers, some with JavaScript turned on and some with JavaScript turned off, would be unable to authenticate from some of their computers and may not ...


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 ...


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 ...


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 ...


0

Well i think the biggest con is that the 3rd factor is either very expensive (iris scans, good facial recognition) and has some downsides. One example is a user who uses his fingerprint to log-on but he cut himself, the system doesn't recognise his print and refuses access. This is why you still can logon with a pin-code on the newest iPhones.


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 ...


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 ...


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 ...


0

This is kind of one of those things that's terribly subjective. What exactly are you trying to protect against here? More questions that need answering: How does B verify that pub key received from A is the right key, and not a MITM key? How are you deriving a private key (pair) from the password? How are you blocking brute force attempts? What ...


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 ...


-1

using a certificate and a password for authentication is NOT considered as a 2FA, since both are utilizing "what you know".


0

PKCS#7 is now standardized by IEFT as CMS, RFC5652.


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 ...


1

Is it necessary to have csrf tokens for login forms? In reference to Wordpress - No, it is not. Login pages are not susceptible to CSRF. The whole premise of CSRF is that the user is already authenticated to the app when the unwanted data is submitted. Per OWASP: "CSRF is an attack which forces an end user to execute unwanted actions on a web ...


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, ...


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. ...


1

A "certificate" by the definition used in cryptography is information about a cryptographic entity in a specific format and signed by a "certificate authority" or CA; X.509 is the most common type of certificate and the one used by PKCS#7 or its updated version CMS (and S/MIME, which is a thin wrapper on CMS). If you want to sign your own data, not special ...



Top 50 recent answers are included