Usually passwords on mobile devices use the PIN as the encryption key (+ some large salt)
This is a possible approach; it has a potential drawback though. The phone cannot get e-mail in the background before the user types in their PIN, then. Also, PINs on a phone are likely to be simple, often numeric codes.
If the user keeps their phone locked, they will want to have something they can key in very quickly to make a phone call in a hurry, which means that the PIN is likely to be brute forceable from a crypto point of view.
I believe typically you still encrypt it with the salt to make things slightly more obscure (prevents against an attack where the exploit allows reading the sqlite db but not where the encryption key is stored).
Obscurity is not security. And with the Android platform, the source code is available to a potential attacker. We can readily anticipate the hacker groups would quickly develop a tool, and publish details, so I wouldn't want to bank on an obscurity element here.
I agree encrypting the password and storing the key somewhere else may prevent an exploit that one case.
Assuming (A) the attacker has the ability to read passwords from the SQLite database, but
(B) the attacker does not have access to read passwords from other SQLite databases, and
(C) your application doesn't store the encryption keys in the same SQLite database as the passwords.
Then it would follow the attacker can't decrypt the passwords.
The only question then would be.... how likely is it that the sqlite database containing the credentials can be compromised but the sqlite database containing decryption keys not be vulnerable?
Which is a difficult question to answer. Clearly though we would be looking at some sort of permissions or SQL injection vulnerability on the primary authentication database.
Any vuln. where the attacker had control of the filesystem or RAM would be at greater risk of immediately exposing both databases.
The SQL injection on the credentials DB could be avoided by keeping the credentials database isolated
from all other functions, and implementing strong filesystem level protections; such as authentication managed
by a separate daemon through privilege separation, inside a different chroot jail, or user-mode filesystem
invisible to other processes, with permissions limiting access to the DB file.
I'm sure most would agree encrypted password data in at least SHA or MD5 would be kind of a good idea!"
No, I would not agree to that. I cannot say what most would think, but they would be misunderstanding the requirements and a misunderstanding
of SHA/MD5 security for password stoarge, if they suggest SHA/MD5 as a solution.
When your android needs to access an e-mail account, knowledge of the actual login password is required,
to connect to the remote server. Storing a SHA or MD5 hash does not retain knowledge of the password, so
automatic e-mail login on the Android device would no longer be able to function with only a SHA or MD5 stored.
The e-mail server itself can potentially store a PBKDF2 derived strong hash for plaintext authentication over TLS (the server
may require plaintext for CRAM-MD5 or other authentication mechanism selections), but your software needs to authenticate
with the mail server, which requires either that actual credentials be stored, OR that credentials be entered by the user.
To quote the complaint from the article:
The password for email accounts is stored into the SQLite DB which in turn stores it on the phone's file system in plain text. Encrypting or at least transforming the password would be desirable.
I will agree that encrypting or transforming the password in the database is possible; something such as a Windows or OSX style keychain should be possible.
HOWEVER, the decryption key has to be stored on the phone, and any transformation has to be reversible, for the device to still work without prompting the user
for the password and saving in RAM or prompting the user every time e-mail is to be checked.
Therefore, the security benefits of doing this are absolutely minimal.
Anyone who is actually trying to extract the password will learn about the transformation, and
any reversible transformation is not a significant improvement.
Saving the unencrypted password in RAM may be just as good [or bad] as saving it on the filesystem, since phones are rarely rebooted,
and RAM is subject to analysis just like a sqlite DB is subject to analysis.
On this we will disagree. If you aren't prepared for the extreme case then your security is, pretty much by definition, ineffective.
Then based on your definition, everyone's security is inherently ineffective, and incapable of being remedied.
By the way, account locking doesn't reduce the chance of a botnet based brute force attack.
A typical botnet brute force attack looks like two or three password attempts on a large dictionary of usernames. A botnet brute force attack does not look like a bunch of botnet nodes attempting to connect as one user; coordination of which node would try which password would be a problem, and as a result would be highly inefficient in any case. Brute force attacks are about getting into an unknown system, as any user, not compromising a specific user. Once any user has been compromised, privilege escalatio techniques are utilized to gain access to other accounts, and ultimately other users' data.
In reality, what is considered effective security implementation is security implementation designed to prevent high probability events, without hurting the business in the process. Because every extra security measure grafted on has a cost, security is not about dealing with extreme examples.
Regardless of security measures taken, there will always be low probability
events that will defeat all security measures, unless the security measures shutdown the business entirely, so that there is no data that arises to be stolen or systems to be compromised in the first place.
For example, a situation equally extreme to a botnet issuing a 1:1 distributed brute force attack against a single user, would be a a group of masked foreign nationals pulls up on a weekend in a black van, armed with machine guns, disables the alarms, with the help of their insider at the alarm company, cuts all comm lines, breaks in, shoots anyone standing in their way on the path to the server room, cuts through all the doors into the server room, and removes all the servers and backup tapes; within 20 minutes the servers are in a different country.
And there's no security measure you can implement that will make that impossible.
The existence of extreme examples such as botnets is no reason to botch the common case of single user, few devices failing authentication, and have the defect of locking an account as a result of a mistake by one device. The security instrumentation of a system that cannot distinguish between a botnet attack on an account and failed login attempts from one device, or a small number of devices, is fundamentally flawwed.
It's really rather simple.... if more than 10 failed login attempts occur to an account, from one IP, ban the IP for 30 minutes. If more than 3 failed login attempts fail to an account, then double the delay before an authentication response whether success or fail, for each successive attempt, up to 10 minutes between attempts.
Oh yeah, and raise the alarm. Because, you see, a 'botnet' attempt at brute force is really the nuclear possibility.
We don't build houses with doors whose locks freeze up if 3 wrong keys are tried and require you to call the locksmith, based on the faint possibility that one day a would-be group of 6000 burglars might come by with 1 key per person.
If your security defenses, alarms, and neighbors don't detect 6000 uninvited burglars in your front lawn, then that would mean you were totally impotent.
Plus you presume a simple brute-force attack rather than a dictionary attack or something even more specific to the target account like names of family members.
All dictionary attacks are brute force attacks.
If your system is susceptible to such a guided brute force attack, then the password security protections are defective.
Applications that need to ensure password security will check passwords against a comprehensive dictionary of english words, common names, employee names, and employee details (e.g. phone numbers).
At which point you are at the same practical result - the only node the user cares about - the one in his hands - is locked out.
What's that? No it's not. Not once they fix their mistake.
How do you propose to stop an attacker who changes IP and/or MAC addresses with every new password attempt?
Well... first of all: if you only saw failed attempts from one or two IP addresses, then you can be quite confident that's not what's happening.
Second: if you see failed attempts to a user in rapid succession from many IP addresses, then you know something is amiss.
You've come up with an unusual theoretical, and quite implausible attack.
There aren't enough IP addresses out there to change IPs after every new password attempt.
IP address is not just a free form field a computer can change to whatever it wants -- the IP address you want to use actually has to be routable, otherwise it's useless.
The only way that makes any sense at all is if the attack source is on the LAN; which means either an internal system has already been compromised, or you have an insider attacking through an inefficient method (trying brute force, when there are much simpler and more successful methods).
As for someone playing with MAC addresses.... it's called Port Security or 802.1x authentication, esp. in the case of wireless.
Layer 2 security issues are not something to ignore, for sure; there are ways of addressing all those, and they need to be addressed on their own merits, anyways.
Apparently iOs devices will retry a failing password over and over locking out the account.
This is a minor nit with the iPad itself, but a MAJOR FLAW in the network device/server the iPad is logging into.
Before you should talk with Apple about this, you need to talk with whatever vendor is providing that server with the account lockout policy that allows one misconfig'ed device to DoS an account.
That is... a sane network login server application would tarpit the network device attempting to login, not lock the account itself.
that looks like applications still will be tied to an user, companies want applications tied to them and be able to move licences between users.
Citrix and Microsoft have similar licensing models.
With citrix/microsoft per-user licensing you assign a license to a user.
It is possible to re-assign a license from one user to another, but once you do so, there is a significant waiting period before you are allowed to re-assign the license again.
The only option besides per-user licensing is per-device licensing.
But per-user is the prevalent licensing option.
So i'm not seeing Apple's per-user method as a major drawback; the corporation still owns that software in any case.
Businesses have a variety of options for deploying iPad across their enterprises. End-users can quickly install configuration profiles to get corporate services up and running. For large scale deployments IT can query and manage devices with Mobile Device Management. iTunes can be customized to fit the needs of both IT and end-users. And, enterprises can also distribute custom iPad apps over-the-air for their users to install.
And IRCwas a two-way messaging protocol that started out as a replacement for NTALK, a network-based variant of TALK(1)+FINGER.
An IRC system is constructed by a peer-to-peer network consisting of a number of IRC Servers, configured
into a tree-based topology designed by the server administrators, and stemming from their choice of which peers to connect together.
IRC clients even had a/NOTIFY command for monitoring presence (or WATCH list) command.
Clients had usermodes they could set on themselves such as/mode yournickname +i (Invisible)
There was a concept of switching channels with a JOIN CHANNELNUMBER command,
with the default channel being 0, later an ability to subscribe to any number of channels using a JOIN #CHANNELNAME command.
Knowledge packets were transmitted to a channel in the IRC protocol using the IRC PRIVMSG command;
abbreviated in most IRC clients to/msg, or simply typing theknowledge packet into a dedicated window for
the channel and using 'enter' to transmit.
Knowledge packets (command buffers) were limited to 512 bytes per message.
Users connecting to IRC subscribe under a certain nickname, their client transmits a USER and NICK command
to select the nickname to subscribe as.
Users could publish private messages to other online users using the PRIVMSG command with the recipient's nickname as the destination. e.g./msg NICKNAME (message here)
In addition to simple private messages, there was a concept of publish NOTICE using a/notice NICKNAME or/notice CHANNEL name command, and channels had a topic configurable with a/TOPIC command, and channel permissions configurable using a/MODE command.
Channel ownership was granted to the first subscriber to the channel.
In the late 1990s IRC developers introduced IRC networks with bolted on registration services for persistence storage of nickname and channel name ownership and permission control.
It became a rich protocol with almost every capability of modern IM clients.
Though some limitations, and many capabilities modern IM clients still don't have.
So what about students of arts programs or journalism programs or science programs or history programs?
There are not billions of $$s in current profits to protect for student art, journalism, science, and history programs.
There is not a big association that sets rules of behavior art students at all schools must follow or be suspended.
And not much news coverage of non-athletes at a university, so the public at large doesn't associate the student
with the university, unless they are some type of ambassador.
If just some art/history/science student makes a stupid posting to Twitter, for the most part it only immediately financially hurts the student.
I'm not suggesting their 'keeping their eyes peeled' is for altruistic reasons.
Now, obviously, if the student has some leadership capacity, such as 'Student Government President', or 'Research Fellow'
in XXX... it will reflect more poorly on the student, and we would probably never hear of it --- they'd get disciplined or ousted in private when their unseemly Twitter post was discovered
This article has occured, most likely, because it _is_ athletes.
The very reason they might target athletes specifically.
They can afford it, with the loot they get from all the chumps who are convinced that life would be incomplete without a proper tethering.
I'm not "shilling" for cell phone companies, and your ad hominem attacks do not support your position at all
rationally.
"Life incomplete without a proper tethering." Is called a straw man argument;
we are not talking about tethering or internet service, and I am not saying everyone has to have a cell phone.
I am saying if you have and rely on a cell phone, it could be life critical.
I'm talking about a cell phone you carry around to make phone calls with,
and the possibility someone could die because police seized a cell phone out of mere suspicion.
If you have an emergency (life threatening or not), you need to use a phone,
or have other provisions in place to get help.
By the way, poor Cell phone networks can also be life threatening... need to dial 911...
oops "No Service"
Other provisions might be a pay phone; but those are exceedingly rare nowadays.
You might get lucky in event of emergency and find someone else to let you use their
phone, or you might not.
had failed to 'adequately and consistently monitor student athletes via phone taps and private investigators' they would be regarded as insane.
There's a difference: telephone conversations are private.
Twitter posts are public.
Sports teams and universities have no duty to ACTIVELY monitor athletes (or other students) to prevent violations. They only have a moral (and sometimes legal) duty to deal openly and fairly when violations come to their attention.
Yes... "when violations come to their attention".
They have a duty to be paying attention though, which includes consuming major publications,
such as local newspapers, major news networks, and (yes) Twitter, for possibly inappropriate statements students have provided for public consumption using their name that is associated with the University and the Football program.
This is not about 'monitoring' students; it's about monitoring public venues to protect the image of their brand, and their football team members are part of their brand -- whatever publicity their football team members create has an effect on the University and Football associations' images in the public eye.
Jeez. It's already been responded to in GP, where I was going to retort but didn't need to. But you persist.
I made a solid case with examples for cell phones being life critical.
Get a fucking life. If having the phone there at your side is so life-critical how did the human species survive for eons before cellphones without them?
Oh, go fuck off, or make an honest, rational proposition.
"Get a fucking life" is not persuading me that you have taken a legitimate position.
If you don't want to discuss a matter you raised, you go get a life.
Your need to bring in dishonest propositions like "go get a life" that do not address the matter
is candid evidence, to suggest you are at a dead end logically and have no rational reasoning left
to support your position that cell phones are not life critical.
Just because human species survived in such poor conditions does not mean individuals fared well.
You can use the same argument to "prove" anti-biotics such as penicillin are not life critical, even if you are afflicted and will die within 24 hours if you don't take the medication. The human race survived without them for eons.
The human race survived without vaccinations too, and all sorts of medical inventions.
That does not mean these things are not life critical; statistically, if you don't get vaccinated
against certain things, you die young.
Fine for refusing to itemize bill: -$1000
Tax writeoff/deduction for administrative 'expenses' settling the matter: CR +$500
Federal tax credit for resolving issue and providing better customer service: CR +$1000
Customer monthly bill increase (carefully hidden in 'regulatory fees section': CR +$10
to top it all off the judge assessed a civil penalty of $1000 dollars against Verizon, as a deterrent for treating customers badly in the future !
Chump change for Verizon... they should have fined them at least a couple million,
with a warning that they were being lenient on this time, because it was a first offense.
If I want ITEMIZED LOCAL CALLS on every bill, I might reasonable expect to pay a small fee.
But if I have a BILLING ISSUE, I expect them to pony up the data as a matter of doing business with me.
What happens if you decide you might have a billing "issue" with every bill?
Sometimes, certain customers can be just as unreasonable as the company's customer service
I don't necessarily agree with your "life critical" reasoning.
Well, it's not quite as bad as police seizing a senior citizen's prescription drugs (including heart medication),
and claiming innocence when they die of a heart attack the next day due to their drugs being seized,
but
A telephone is life critical as soon as you need to call 911 and cannot, because the police have taken your phone. Or you have your child calling you for help, but cannot answer, because your phone is gone.
Many people have a cell phone as their sole communications device, pay all their bills using their phone, and through smartphone based payment, the phone is essentially the payment method for many transactions.
It can also pose other problems beyond minor inconvenience -- for example, exposure of confidential work e-mails (assuming the officer didn't do something with the phone that caused a remote-wipe to be initiated).
Loss of ability to make contact for various services and receive potentially critical phone calls of various natures.
It is an inconvenience that noone should be allowed to impose for a light, transitory reason or mere "suspicion".
if the police were only to take 10 minutes to copy the data and then return the device the defense lawyers would throw a fit and would argue how can it be proved that data came from a phone that is no longer in their possession.
Police officers that intend to analyze a phone should bring a hardware data dumper with them, with logic for the appropriate type of phone to gather all information, and the hardware dumper should utilize trusted hardware cryptography to certify and digitally sign the combination of the serial number/IMEI of the device being data dumped along with a physical profile/picture of the device captured.
If they wish to hold on to the device longer, law enforcement should be required to meet a much higher standard of suspicion than "just investigating a possible suspect".
I'll be the first to say that that is excessive, but 10 minutes is rather brief.
A hard drive is larger and therefore takes longer to dump the data off of.
The police should be required to dispatch a 'data dumper' to the site where an image is to be taken.
The amount of time they are allowed to hold the hard drive should be based on the speed of the hard drive, and the total amount of time required for the drive to read and spit out all data to the dumper/logger device.
I believe law enforcement should be allowed to hold a hard drive for a maximum of 24 hours in any case,
unless the evidence sought is solely a physical property of the device (for example, a bloodstain or fingerprint located on the hard drive case).
So it is extremely odious that police take away
a person's cell phone, if the person is not being arrested
or at least charged with a crime.
This is a far more significant breach than mere 4th amendment stuff.
Police are looking for information you have recorded,
instead of evidence of a crime.
The routine taking away of life-critical devices from 'suspects'
is a menace to society.
This does more harm to innocent people than criminals.
For people who rely on their smart phones for all communications,
this would be similar to police impounding the right arm or left foot of suspects,
to attempt to 'analyze' if they held a weapon, and demanding DNA from random
people at a scene who are 'suspects' (whether there is actual cause to suspect them or not
beyond mere presence/appearance).
This should be solved legally and technologically dealt with.
Cell-phones should regularly purge latent/hidden data when charging
AND resist attempts to gather data from them.
If someone is a suspect, the police should have to get a special warrant
to access cell phone data, and it should be served not by confiscating
the physical device, but by the court granting the police 10 minutes to
hold the suspect's phone, during which all "data capture" must be completed.
If the physical phone is confiscated under a warrant for confiscation of the phone,
then only physical aspects of the phone should be subject to analysis, not private data
the user had stored, unless previously discovered
Other than being a decent applied cryptography experiment, BitCoin has no real use in the real world. It isn't anonymous, it isn't backed by anyone that matters. The currency is too unstable to trust for anything. Its architecture gives a lot more power to people who come on early, and whom likely are going to cash out if people catch on.
More power to people who come early.... sounds a lot like the domain name system....
Speaking of which, perhaps Bitcoin transactions could be used to facilitate a replacement for hierarchical DNS,
due to the public and forever verifiable nature of Bitcoin transactions, you have a distributed database much like
DNS, that is also peer-to-peer and universally verifiable, a technology like Bitcoin would always be able to
"prove" who asked to register for a name first, and if a bitcoin transaction was required for it to happen,
the registration action be free, abuse/squatting would be self-limiting, "expiration" after X years
of registration would not be required, and it could be made impossible for a central authority to revoke a name
registration based on "legal" demands, DMCA, etc....
The missionary church of kopimis is in contradiction with itself (http://kopimistsamfundet.se/english/).
It's not a contradiction. Just because they hold sharing of information as sacred, and the religion prescribes its followers should share information,
does not necessarily mean the religion allows them to eavesdrop to obtain that information.
That's akin to a religion requiring members donate all their money to the church, BUT just because donations are held sacred,
and believers are required to donate, does not mean the religion has to allow followers to steal money from one another to give to the church.
And does not necessarily mean the church must not hold sinful acts such as robbery.
Sharing the information may be right and true, but the way information was obtained to share might be considered sinful by their church.
Slashdot Mirror
Usually passwords on mobile devices use the PIN as the encryption key (+ some large salt)
This is a possible approach; it has a potential drawback though. The phone cannot get e-mail in the background before the user types in their PIN, then. Also, PINs on a phone are likely to be simple, often numeric codes. If the user keeps their phone locked, they will want to have something they can key in very quickly to make a phone call in a hurry, which means that the PIN is likely to be brute forceable from a crypto point of view.
I believe typically you still encrypt it with the salt to make things slightly more obscure (prevents against an attack where the exploit allows reading the sqlite db but not where the encryption key is stored).
Obscurity is not security. And with the Android platform, the source code is available to a potential attacker. We can readily anticipate the hacker groups would quickly develop a tool, and publish details, so I wouldn't want to bank on an obscurity element here.
I agree encrypting the password and storing the key somewhere else may prevent an exploit that one case. Assuming (A) the attacker has the ability to read passwords from the SQLite database, but (B) the attacker does not have access to read passwords from other SQLite databases, and (C) your application doesn't store the encryption keys in the same SQLite database as the passwords.
Then it would follow the attacker can't decrypt the passwords.
The only question then would be.... how likely is it that the sqlite database containing the credentials can be compromised but the sqlite database containing decryption keys not be vulnerable?
Which is a difficult question to answer. Clearly though we would be looking at some sort of permissions or SQL injection vulnerability on the primary authentication database. Any vuln. where the attacker had control of the filesystem or RAM would be at greater risk of immediately exposing both databases.
The SQL injection on the credentials DB could be avoided by keeping the credentials database isolated from all other functions, and implementing strong filesystem level protections; such as authentication managed by a separate daemon through privilege separation, inside a different chroot jail, or user-mode filesystem invisible to other processes, with permissions limiting access to the DB file.
I'm sure most would agree encrypted password data in at least SHA or MD5 would be kind of a good idea!"
No, I would not agree to that. I cannot say what most would think, but they would be misunderstanding the requirements and a misunderstanding of SHA/MD5 security for password stoarge, if they suggest SHA/MD5 as a solution.
When your android needs to access an e-mail account, knowledge of the actual login password is required, to connect to the remote server. Storing a SHA or MD5 hash does not retain knowledge of the password, so automatic e-mail login on the Android device would no longer be able to function with only a SHA or MD5 stored.
The e-mail server itself can potentially store a PBKDF2 derived strong hash for plaintext authentication over TLS (the server may require plaintext for CRAM-MD5 or other authentication mechanism selections), but your software needs to authenticate with the mail server, which requires either that actual credentials be stored, OR that credentials be entered by the user.
To quote the complaint from the article:
The password for email accounts is stored into the SQLite DB which in turn stores it on the phone's file system in plain text. Encrypting or at least transforming the password would be desirable.
I will agree that encrypting or transforming the password in the database is possible; something such as a Windows or OSX style keychain should be possible. HOWEVER, the decryption key has to be stored on the phone, and any transformation has to be reversible, for the device to still work without prompting the user for the password and saving in RAM or prompting the user every time e-mail is to be checked.
Therefore, the security benefits of doing this are absolutely minimal. Anyone who is actually trying to extract the password will learn about the transformation, and any reversible transformation is not a significant improvement.
Saving the unencrypted password in RAM may be just as good [or bad] as saving it on the filesystem, since phones are rarely rebooted, and RAM is subject to analysis just like a sqlite DB is subject to analysis.
On this we will disagree. If you aren't prepared for the extreme case then your security is, pretty much by definition, ineffective.
Then based on your definition, everyone's security is inherently ineffective, and incapable of being remedied.
By the way, account locking doesn't reduce the chance of a botnet based brute force attack. A typical botnet brute force attack looks like two or three password attempts on a large dictionary of usernames. A botnet brute force attack does not look like a bunch of botnet nodes attempting to connect as one user; coordination of which node would try which password would be a problem, and as a result would be highly inefficient in any case. Brute force attacks are about getting into an unknown system, as any user, not compromising a specific user. Once any user has been compromised, privilege escalatio techniques are utilized to gain access to other accounts, and ultimately other users' data.
In reality, what is considered effective security implementation is security implementation designed to prevent high probability events, without hurting the business in the process. Because every extra security measure grafted on has a cost, security is not about dealing with extreme examples.
Regardless of security measures taken, there will always be low probability events that will defeat all security measures, unless the security measures shutdown the business entirely, so that there is no data that arises to be stolen or systems to be compromised in the first place.
For example, a situation equally extreme to a botnet issuing a 1:1 distributed brute force attack against a single user, would be a a group of masked foreign nationals pulls up on a weekend in a black van, armed with machine guns, disables the alarms, with the help of their insider at the alarm company, cuts all comm lines, breaks in, shoots anyone standing in their way on the path to the server room, cuts through all the doors into the server room, and removes all the servers and backup tapes; within 20 minutes the servers are in a different country.
And there's no security measure you can implement that will make that impossible.
Botnets.
The existence of extreme examples such as botnets is no reason to botch the common case of single user, few devices failing authentication, and have the defect of locking an account as a result of a mistake by one device. The security instrumentation of a system that cannot distinguish between a botnet attack on an account and failed login attempts from one device, or a small number of devices, is fundamentally flawwed.
It's really rather simple.... if more than 10 failed login attempts occur to an account, from one IP, ban the IP for 30 minutes. If more than 3 failed login attempts fail to an account, then double the delay before an authentication response whether success or fail, for each successive attempt, up to 10 minutes between attempts.
Oh yeah, and raise the alarm. Because, you see, a 'botnet' attempt at brute force is really the nuclear possibility. We don't build houses with doors whose locks freeze up if 3 wrong keys are tried and require you to call the locksmith, based on the faint possibility that one day a would-be group of 6000 burglars might come by with 1 key per person.
If your security defenses, alarms, and neighbors don't detect 6000 uninvited burglars in your front lawn, then that would mean you were totally impotent.
Plus you presume a simple brute-force attack rather than a dictionary attack or something even more specific to the target account like names of family members.
All dictionary attacks are brute force attacks.
If your system is susceptible to such a guided brute force attack, then the password security protections are defective. Applications that need to ensure password security will check passwords against a comprehensive dictionary of english words, common names, employee names, and employee details (e.g. phone numbers).
At which point you are at the same practical result - the only node the user cares about - the one in his hands - is locked out.
What's that? No it's not. Not once they fix their mistake.
How do you propose to stop an attacker who changes IP and/or MAC addresses with every new password attempt?
Well... first of all: if you only saw failed attempts from one or two IP addresses, then you can be quite confident that's not what's happening. Second: if you see failed attempts to a user in rapid succession from many IP addresses, then you know something is amiss.
You've come up with an unusual theoretical, and quite implausible attack. There aren't enough IP addresses out there to change IPs after every new password attempt.
IP address is not just a free form field a computer can change to whatever it wants -- the IP address you want to use actually has to be routable, otherwise it's useless.
The only way that makes any sense at all is if the attack source is on the LAN; which means either an internal system has already been compromised, or you have an insider attacking through an inefficient method (trying brute force, when there are much simpler and more successful methods).
As for someone playing with MAC addresses.... it's called Port Security or 802.1x authentication, esp. in the case of wireless.
Layer 2 security issues are not something to ignore, for sure; there are ways of addressing all those, and they need to be addressed on their own merits, anyways.
Apparently iOs devices will retry a failing password over and over locking out the account.
This is a minor nit with the iPad itself, but a MAJOR FLAW in the network device/server the iPad is logging into.
Before you should talk with Apple about this, you need to talk with whatever vendor is providing that server with the account lockout policy that allows one misconfig'ed device to DoS an account.
That is... a sane network login server application would tarpit the network device attempting to login, not lock the account itself.
that looks like applications still will be tied to an user, companies want applications tied to them and be able to move licences between users.
Citrix and Microsoft have similar licensing models.
With citrix/microsoft per-user licensing you assign a license to a user. It is possible to re-assign a license from one user to another, but once you do so, there is a significant waiting period before you are allowed to re-assign the license again.
The only option besides per-user licensing is per-device licensing. But per-user is the prevalent licensing option. So i'm not seeing Apple's per-user method as a major drawback; the corporation still owns that software in any case.
And they also have integration through MDM:
Businesses have a variety of options for deploying iPad across their enterprises. End-users can quickly install configuration profiles to get corporate services up and running. For large scale deployments IT can query and manage devices with Mobile Device Management. iTunes can be customized to fit the needs of both IT and end-users. And, enterprises can also distribute custom iPad apps over-the-air for their users to install.
You mean like Gandhicam ?
And IRCwas a two-way messaging protocol that started out as a replacement for NTALK, a network-based variant of TALK(1)+FINGER. An IRC system is constructed by a peer-to-peer network consisting of a number of IRC Servers, configured into a tree-based topology designed by the server administrators, and stemming from their choice of which peers to connect together.
IRC clients even had a /NOTIFY command for monitoring presence (or WATCH list) command.
Clients had usermodes they could set on themselves such as /mode yournickname +i (Invisible)
There was a concept of switching channels with a JOIN CHANNELNUMBER command, with the default channel being 0, later an ability to subscribe to any number of channels using a JOIN #CHANNELNAME command.
Knowledge packets were transmitted to a channel in the IRC protocol using the IRC PRIVMSG command; abbreviated in most IRC clients to /msg, or simply typing theknowledge packet into a dedicated window for
the channel and using 'enter' to transmit.
Knowledge packets (command buffers) were limited to 512 bytes per message.
Users connecting to IRC subscribe under a certain nickname, their client transmits a USER and NICK command to select the nickname to subscribe as. Users could publish private messages to other online users using the PRIVMSG command with the recipient's nickname as the destination. e.g. /msg NICKNAME (message here)
In addition to simple private messages, there was a concept of publish NOTICE using a /notice NICKNAME or /notice CHANNEL name command, and channels had a topic configurable with a /TOPIC command, and channel permissions configurable using a /MODE command.
Channel ownership was granted to the first subscriber to the channel. In the late 1990s IRC developers introduced IRC networks with bolted on registration services for persistence storage of nickname and channel name ownership and permission control.
It became a rich protocol with almost every capability of modern IM clients. Though some limitations, and many capabilities modern IM clients still don't have.
So what about students of arts programs or journalism programs or science programs or history programs?
There are not billions of $$s in current profits to protect for student art, journalism, science, and history programs. There is not a big association that sets rules of behavior art students at all schools must follow or be suspended.
And not much news coverage of non-athletes at a university, so the public at large doesn't associate the student with the university, unless they are some type of ambassador.
If just some art/history/science student makes a stupid posting to Twitter, for the most part it only immediately financially hurts the student.
I'm not suggesting their 'keeping their eyes peeled' is for altruistic reasons.
Now, obviously, if the student has some leadership capacity, such as 'Student Government President', or 'Research Fellow' in XXX... it will reflect more poorly on the student, and we would probably never hear of it --- they'd get disciplined or ousted in private when their unseemly Twitter post was discovered
This article has occured, most likely, because it _is_ athletes. The very reason they might target athletes specifically.
They can afford it, with the loot they get from all the chumps who are convinced that life would be incomplete without a proper tethering.
I'm not "shilling" for cell phone companies, and your ad hominem attacks do not support your position at all rationally.
"Life incomplete without a proper tethering." Is called a straw man argument; we are not talking about tethering or internet service, and I am not saying everyone has to have a cell phone.
I am saying if you have and rely on a cell phone, it could be life critical. I'm talking about a cell phone you carry around to make phone calls with, and the possibility someone could die because police seized a cell phone out of mere suspicion.
If you have an emergency (life threatening or not), you need to use a phone, or have other provisions in place to get help. By the way, poor Cell phone networks can also be life threatening... need to dial 911... oops "No Service"
Other provisions might be a pay phone; but those are exceedingly rare nowadays. You might get lucky in event of emergency and find someone else to let you use their phone, or you might not.
Monitoring of students should be done by parents, legal guardians and baby sitters.
College students usually don't have legal guardians or baby sitters; most are 18, the age of majority, or older.
had failed to 'adequately and consistently monitor student athletes via phone taps and private investigators' they would be regarded as insane.
There's a difference: telephone conversations are private. Twitter posts are public.
Sports teams and universities have no duty to ACTIVELY monitor athletes (or other students) to prevent violations. They only have a moral (and sometimes legal) duty to deal openly and fairly when violations come to their attention.
Yes... "when violations come to their attention". They have a duty to be paying attention though, which includes consuming major publications, such as local newspapers, major news networks, and (yes) Twitter, for possibly inappropriate statements students have provided for public consumption using their name that is associated with the University and the Football program.
This is not about 'monitoring' students; it's about monitoring public venues to protect the image of their brand, and their football team members are part of their brand -- whatever publicity their football team members create has an effect on the University and Football associations' images in the public eye.
Jeez. It's already been responded to in GP, where I was going to retort but didn't need to. But you persist.
I made a solid case with examples for cell phones being life critical.
Get a fucking life. If having the phone there at your side is so life-critical how did the human species survive for eons before cellphones without them?
Oh, go fuck off, or make an honest, rational proposition. "Get a fucking life" is not persuading me that you have taken a legitimate position. If you don't want to discuss a matter you raised, you go get a life.
Your need to bring in dishonest propositions like "go get a life" that do not address the matter is candid evidence, to suggest you are at a dead end logically and have no rational reasoning left to support your position that cell phones are not life critical.
Just because human species survived in such poor conditions does not mean individuals fared well.
You can use the same argument to "prove" anti-biotics such as penicillin are not life critical, even if you are afflicted and will die within 24 hours if you don't take the medication. The human race survived without them for eons.
The human race survived without vaccinations too, and all sorts of medical inventions. That does not mean these things are not life critical; statistically, if you don't get vaccinated against certain things, you die young.
Did Verizon ask to see that fine itemized?
Fine for refusing to itemize bill: -$1000
Tax writeoff/deduction for administrative 'expenses' settling the matter: CR +$500
Federal tax credit for resolving issue and providing better customer service: CR +$1000
Customer monthly bill increase (carefully hidden in 'regulatory fees section': CR +$10
Amount Due: -$510.
to top it all off the judge assessed a civil penalty of $1000 dollars against Verizon, as a deterrent for treating customers badly in the future !
Chump change for Verizon... they should have fined them at least a couple million, with a warning that they were being lenient on this time, because it was a first offense.
If I want ITEMIZED LOCAL CALLS on every bill, I might reasonable expect to pay a small fee. But if I have a BILLING ISSUE, I expect them to pony up the data as a matter of doing business with me.
What happens if you decide you might have a billing "issue" with every bill?
Sometimes, certain customers can be just as unreasonable as the company's customer service
I don't necessarily agree with your "life critical" reasoning.
Well, it's not quite as bad as police seizing a senior citizen's prescription drugs (including heart medication), and claiming innocence when they die of a heart attack the next day due to their drugs being seized, but
A telephone is life critical as soon as you need to call 911 and cannot, because the police have taken your phone. Or you have your child calling you for help, but cannot answer, because your phone is gone.
Many people have a cell phone as their sole communications device, pay all their bills using their phone, and through smartphone based payment, the phone is essentially the payment method for many transactions.
It can also pose other problems beyond minor inconvenience -- for example, exposure of confidential work e-mails (assuming the officer didn't do something with the phone that caused a remote-wipe to be initiated).
Loss of ability to make contact for various services and receive potentially critical phone calls of various natures.
It is an inconvenience that noone should be allowed to impose for a light, transitory reason or mere "suspicion".
if the police were only to take 10 minutes to copy the data and then return the device the defense lawyers would throw a fit and would argue how can it be proved that data came from a phone that is no longer in their possession.
Police officers that intend to analyze a phone should bring a hardware data dumper with them, with logic for the appropriate type of phone to gather all information, and the hardware dumper should utilize trusted hardware cryptography to certify and digitally sign the combination of the serial number/IMEI of the device being data dumped along with a physical profile/picture of the device captured.
If they wish to hold on to the device longer, law enforcement should be required to meet a much higher standard of suspicion than "just investigating a possible suspect".
I'll be the first to say that that is excessive, but 10 minutes is rather brief.
A hard drive is larger and therefore takes longer to dump the data off of. The police should be required to dispatch a 'data dumper' to the site where an image is to be taken. The amount of time they are allowed to hold the hard drive should be based on the speed of the hard drive, and the total amount of time required for the drive to read and spit out all data to the dumper/logger device.
I believe law enforcement should be allowed to hold a hard drive for a maximum of 24 hours in any case, unless the evidence sought is solely a physical property of the device (for example, a bloodstain or fingerprint located on the hard drive case).
Your smartphone is your data.
So it is extremely odious that police take away a person's cell phone, if the person is not being arrested or at least charged with a crime.
This is a far more significant breach than mere 4th amendment stuff. Police are looking for information you have recorded, instead of evidence of a crime.
The routine taking away of life-critical devices from 'suspects' is a menace to society. This does more harm to innocent people than criminals.
For people who rely on their smart phones for all communications, this would be similar to police impounding the right arm or left foot of suspects, to attempt to 'analyze' if they held a weapon, and demanding DNA from random people at a scene who are 'suspects' (whether there is actual cause to suspect them or not beyond mere presence/appearance).
This should be solved legally and technologically dealt with. Cell-phones should regularly purge latent/hidden data when charging AND resist attempts to gather data from them.
If someone is a suspect, the police should have to get a special warrant to access cell phone data, and it should be served not by confiscating the physical device, but by the court granting the police 10 minutes to hold the suspect's phone, during which all "data capture" must be completed.
If the physical phone is confiscated under a warrant for confiscation of the phone, then only physical aspects of the phone should be subject to analysis, not private data the user had stored, unless previously discovered
"What the hell do you call an OS like that?"
An core OS for Windows to run on top of, in the future
Other than being a decent applied cryptography experiment, BitCoin has no real use in the real world. It isn't anonymous, it isn't backed by anyone that matters. The currency is too unstable to trust for anything. Its architecture gives a lot more power to people who come on early, and whom likely are going to cash out if people catch on.
More power to people who come early.... sounds a lot like the domain name system....
Speaking of which, perhaps Bitcoin transactions could be used to facilitate a replacement for hierarchical DNS, due to the public and forever verifiable nature of Bitcoin transactions, you have a distributed database much like DNS, that is also peer-to-peer and universally verifiable, a technology like Bitcoin would always be able to "prove" who asked to register for a name first, and if a bitcoin transaction was required for it to happen, the registration action be free, abuse/squatting would be self-limiting, "expiration" after X years of registration would not be required, and it could be made impossible for a central authority to revoke a name registration based on "legal" demands, DMCA, etc....
The missionary church of kopimis is in contradiction with itself (http://kopimistsamfundet.se/english/).
It's not a contradiction. Just because they hold sharing of information as sacred, and the religion prescribes its followers should share information, does not necessarily mean the religion allows them to eavesdrop to obtain that information.
That's akin to a religion requiring members donate all their money to the church, BUT just because donations are held sacred, and believers are required to donate, does not mean the religion has to allow followers to steal money from one another to give to the church.
And does not necessarily mean the church must not hold sinful acts such as robbery.
Sharing the information may be right and true, but the way information was obtained to share might be considered sinful by their church.