Tag Info

New answers tagged

0

Android uses AccountManager to store the passwords. By rooting a phone you can access the encrypted store. What happends now depends on the password you use to lock your phone (from which is derived the encryption key for the store). As you can imagine, a 4 digits PIN is not going to resist long. A fingerprint (or other mechanism with large entropy) will ...


1

Here's a little drawing: And the study that support it.


0

Disclaimer: I have never used ruby / ruby on rails and in this answer I describe how I would act in general. You have two ways to solve this problem: Use an additional user for all your searches. Pro: You don't have to store the users credentials after he/she logged in. Con: I don't know if this matters in your application but you can't track which user ...


0

Yes, and in fact there is such a password manager, that uses gpg for the encryption. It's called pass, and it's available at http://www.passwordstore.org/ for linux/Unix. With pass, each password lives inside of a gpg encrypted file whose filename is the title of the website or resource that requires the password. These encrypted files may be ...


1

Services such as LastPass have an auto change password feature. However, this has to be done per site. The solution of bulk updating everything is to a problem that should not exist in the first place. i.e. Passwords should not be shared between applications. Each service should have a unique, strong password of its own. Otherwise if one service gets ...


1

Interesting topic, for me the safest is password, I use 4 different passwords for different things depending on the security required, for example for a site like this I will use something like (mexico1970) which I dont care if it gets cracked since I just post to the site and there is no credit card info or any other important info to protect, then I will ...


0

A little late to the party - I recently read that the reason for this is that for many banks, the value of the increased security of allowing those characters is outweighed by the implementation cost and the support cost of dealing with customers that cannot remember their passwords. I'm not saying that its a good reason, but that is how I interpreted ...


2

Protecting the root account makes cleanup much easier: if an attacker can't tamper with the kernel or most of the programs, it's much harder to hide malicious code. It also means they can't tamper with the antivirus and other protection systems.


1

To put you on the right track, we must first take you out of the wrong track. In your case: If you think "268 + 268 + 108", then you are thinking wrong. That would be the count of possible passwords, assuming that a password is either a sequence of eight uppercase letters, OR a sequence of eight lowercase letters, OR a sequence of eight digits. But that's ...


0

Question (a) There are (26+26+10)^8 different passwords = 218,340,105,584,896. Call that the dictionary_size. The attacker can test 4*10^6 per second => tests_per_hour: (60*60)*4*10^6 = 14,400,000,000 On average he will have to test half the dictionary, to find the average password solution: dictionary_size / 2 / tests_per_hour = 7581.25 hours. ...


0

The question isn't asking you to relate the answers to A and C, it's only saying that an attacker would realize that A is not the most efficient solution if he has more than one batch of passwords to guess, because he can get more than one use out of a rainbow table of 8 character SHA-256 hashed words. So you need to compute the number of possible ...


0

It's asking how many bytes of storage are necessary to store all possible hashes and one password that hashes to it. The way to look at this is to calculate the total number of passwords, then multiply that by the total space required to store both the password and its hash. So, if you have 10 possible passwords requiring 1byte to store each, and you ...


2

The credentials may be shared for the whole network (eg. LDAP credentials), allowing access to the local computer, mail, remote access… Also note that Phishing OS credentials is very different than phishing a website. You don't go back to a computer and fill an Email prompt without even logging in (actually, I don't think many company users enter their ...


2

The system-attention-key is mostly an historical remnant from the youth days of the engineers who designed the SAK. These engineers, when they think about security, actually think about the times when they were dabbling in security, and that was when they were students. More precisely, when they were students in the 1990s. That last item is important: in the ...


0

Do not try to reinvent the wheel. Do not sacrifice security for usability The existing password resetting schemes are already tested and validated against access control threats. They are not perfect but they are accepted. The approach you propose to reset the password is very weak. Think about that I am an attacker. I do not need to go after the ...


2

I would not recommend doing what you are trying to do. As you pointed out, the question/answer is much less secure than a normal user/pass, and security is only as effective as the weakest link, and obviously this sort of implementation is the weak link. Also, as an aside, it may be difficult to remember which security question was originally selected. Your ...


2

In this circumstance, it seems like the security answer effectively becomes an alternative password That's right. Which is also why this seems like a really bad idea. It will only work as a feature if the question is something simple, something the user will know without having to remember it, which means that an attacker can figure it out as well (by ...


1

While this is an interesting idea, I would suggest keeping it normal as you have it but give users option for 2 factor authentication in their account settings. In this when a user successfully enters their credentials, they would be emailed a link to click / follow. Once followed their session would be started. You have to assume your clients are stupid, ...


3

If you are allowing people to use personal accounts for external services like dropbox, you really have no control and you do not own those. Most services that offer a corporate or business version have the ability to set one or more administrators, and can disable the accounts through this interface. From a process standpoint, some organizations do this by ...


2

Short version: Your solution sacrifices logging and auditing accountability, just so as you're aware. If direct root login is a problem, use a generic non-admin user to ssh in and then sudo to root. If you want to be clever, configure sudo (via pam) to prompt for a human-specific username and password so that local privilege escalation is tied to the ...


2

I recommend that you do not permit direct login as root via ssh on any system. As mentioned in gowenfawr's comment above, it is better to have personal accounts for everyone who will be administering the system on all of the nodes, and give them access to sudo to root locally. They would not need a root password on any node for this; they would use their own ...


1

I think there is a serious flaw in your suggestion: unless I miss my mark, your "salt" isn't a salt at all: it's a challenge and, as such, it should be randomly generated each time a client attempts to authenticate. If this is the case, then you cannot use it as input for the pbkdf2 function. It will just not work. If it is not the case, then unless you're ...


0

They should be stored in plaintext, or base64 encoded. You can refer to how Tomcat is configured <!-- Define a SSL Coyote HTTP/1.1 Connector on port 8443 --> <Connector protocol="org.apache.coyote.http11.Http11NioProtocol" port="8443" maxThreads="200" scheme="https" secure="true" SSLEnabled="true" ...


2

Well I would have to say that this is less secure than a standard password even though a initial glance shows that the entropy will be far greater You are limiting answers to "dictionary words" and more often than not a small subset of them ( for example what was your favroute childhood food would have less than 20,000 possible options and I would say ...


3

Some issues with this: Signup would take a long time. That would be a major deterrent for many websites. Privacy, you get a lot of information about someone and if it's not something that everyone knows then obviously it's personal. It's one thing if your password table ends up on the streets, it's another when I can find out all kinds of tidbits about ...


0

It is certainly not illegal to store or display plain text passwords in general. There are some best practices that should be considered. For example, if the website is accessible over the internet then SSL should be used anytime you are displaying a password. Even for internal only sites this is still a good idea. If passwords are being displayed, that ...


0

Theres no law regarding passwords. Only law that exists applies to personal details, but a password is not a personal detail. Since the password is often selected by the end user, under EU law this will Count as consent too, so even if someone would enter personal details as their password, it would Count as consent. Depending on what the password protects, ...



Top 50 recent answers are included