RIM, BlackBerry alla riscossa

Il produttore canadese suona la carica e si prepara a tornare protagonista sulla scena degli smartphone. Con un nuovo OS, tanto entusiasmo e con un numero di sottoscrittori che cresce

Roma – Il futuro di BlackBerry è rosa, dice Research In Motion: nel presentare il nuovo OS BlackBerry 10 in un meeting in quel di San Jose (California), il CEO della produttrice canadese snocciola numeri a dir poco incoraggianti e promette il ritorno in auge del marchio che ha popolarizzato gli smartphone presso le aziende e il pubblico professionale.

Sappiamo di dover cambiare, ha detto il CEO Thorsten Heins, e con BlackBerry 10 RIM ha intenzione di realizzare un nuovo punto di svolta per l’intero mondo del mobile: l’OS offrirà una nuova interfaccia, nuove app, nuove modalità di gestione dei singoli applicativi (che non necessiteranno di svariate pagine da scorrere una ad una come capita ora su iOS e Android) e una maggiore integrazione fra il mondo lavorativo e quello personale per i professionisti.

Grazie a BlackBerry Balance, infatti, l’utente potrà fare la spola fra due diversi set di app e servizi, uno da usare per il lavoro e l’altro per motivi e finalità private che nulla hanno a che fare con l’ambiente aziendale. La piattaforma BlackBerry 10 influenzerà i prossimi 10 anni dei dispositivi mobile così come BlackBerry ha influenzato l’ultima decade, ha promesso baldanzoso Heins.

RIM vuole tornare grande, vuole tornare almeno a contare per terzo nel mercato degli ecosistemi per smartphone e per corroborare questa fiducia nel futuro comunica di aver raggiunto la bellezza di 80 milioni di sottoscrittori : solo negli ultimi 3 mesi, dice la società canadese, se ne sono aggiunti 2 milioni.

RIM cresce, si prepara a rinnovare la propria offerta di app e contenuti sul marketplace “App World” ma non dimentica le proprie origini e l’importanza della tastiera fisica in standard QWERTY per gli utenti professionali. L’ottimismo della società dei BlackBerry raggiunge il cacume quando il management si mette a strimpellare e cantare un motivetto pop per dire agli sviluppatori di app: “RIM vi vuole ancora bene”.

Alfonso Maruccia

La tua email sarà utilizzata per comunicarti se qualcuno risponde al tuo commento e non sarà pubblicato. Dichiari di avere preso visione e di accettare quanto previsto dalla informativa privacy

  • eymerich scrive:
    YouPorn & IEEE
    Ma è esattamente la stessa distribuzione delle password che hanno trovato quando hanno bucato YouPorn!
    • pignolo scrive:
      Re: YouPorn & IEEE
      - Scritto da: eymerich
      Ma è esattamente la stessa distribuzione delle
      password che hanno trovato quando hanno bucato
      YouPorn!sarà mica che gli iscritti erano gli stessi! :s :$
  • panda rossa scrive:
    Ma perche' le salvano in chiaro?
    Io non mi capacito di come ancora ci siano realta' che salvano le password in chiaro.Le password devono essere sempre criptate.E' assurdo che da qualunque parte vi sia un luogo con le password in chiaro.
    • giuliaI scrive:
      Re: Ma perche' le salvano in chiaro?
      - Scritto da: panda rossa
      Io non mi capacito di come ancora ci siano
      realta' che salvano le password in
      chiaro.
      già..
    • underpaid_d eveloper scrive:
      Re: Ma perche' le salvano in chiaro?
      Concordo in pieno.Si potrebbe anche discutere sul fatto che l'utente medio si ostini ad usare password come 123456!!!
      • panda rossa scrive:
        Re: Ma perche' le salvano in chiaro?
        - Scritto da: underpaid_d eveloper
        Concordo in pieno.
        Si potrebbe anche discutere sul fatto che
        l'utente medio si ostini ad usare password come
        123456!!!L'utente medio puo' usare la password che gli pare: i sistemi per difendersi da un brute force attack ci sono.Ma se uno adotta una password anti brute force, ma il server la salva in chiaro e poi si fa bucare, come ti difendi?
        • underpaid_d eveloper scrive:
          Re: Ma perche' le salvano in chiaro?
          Per entrare sul server devi sapere la password, quindi anche se è salvata in chiaro, il cracker non arriva a vederla in quanto il db sta dietro la stessa.Io sottolineavo il fatto che una password idiota è più pericolosa della password in chiaro.Un craker di media intelligenza non tenta un brute force attack generando password casuali, ma creando uno script ad-hoc che pesca da un "dizionario"delle password più comuni.Indovina qual'è la prima password che prova? Esatto!!
          • tucumcari scrive:
            Re: Ma perche' le salvano in chiaro?
            - Scritto da: underpaid_d eveloper
            Per entrare sul server devi sapere la password,
            quindi anche se è salvata in chiaro, il cracker
            non arriva a vederla in quanto il db sta dietro
            la
            stessa.
            Io sottolineavo il fatto che una password idiota
            è più pericolosa della password in
            chiaro.
            Un craker di media intelligenza non tenta un
            brute force attack generando password casuali, ma
            creando uno script ad-hoc che pesca da un
            "dizionario"
            delle password più comuni.
            Indovina qual'è la prima password che prova?
            Esatto!!Per evitare le password troppo stupide si può testarle (i sistemi di feedback ci sono e lavorano bene) e rifiutarle...Certo ci sono anche i generatori di password che risolvono in maniera "draconiana" la questione ma agli utenti in genere non piace....
          • underpaid_d eveloper scrive:
            Re: Ma perche' le salvano in chiaro?
            La regola è semplice: - Minimo 6 caratteri - Obbigo di maiuscoe + minuscole - Obbligo di caratteri specialiRegola numero 2:Meglio un cliente scontento che un cliente derubato
          • daniele_dll _rosica scrive:
            Re: Ma perche' le salvano in chiaro?
            - Scritto da: underpaid_d eveloper
            La regola è semplice:
            - Minimo 6 caratteri
            - Obbigo di maiuscoe + minuscole
            - Obbligo di caratteri speciali

            Regola numero 2:
            Meglio un cliente scontento che un cliente
            derubatopiù obbligo di numeri ma minimo 8 caratteri :)
    • tucumcari scrive:
      Re: Ma perche' le salvano in chiaro?
      - Scritto da: panda rossa
      Io non mi capacito di come ancora ci siano
      realta' che salvano le password in
      chiaro.

      Le password devono essere sempre criptate.Purtroppo io non mi meraviglio più di nulla Mi capita (facendo l'auditor di sicurezza in varie aziende e enti) di vedere cose a cui davvero non vorresti ne credere ne vedere...E molto spesso il problema non è quello che in questi posti non ci sia gente competente.In genere il problema è che le responsabilità e le procedure vengono affidati in base a organigrammi parental-amicali o (peggio) sulla base della "fedeltà" al capo...E i competenti invece fuori dalle balle almeno fino a che non hanno fatto e completato il dovuto "corso di paraculismo organizzativo" (non saprei come meglio definire le cose) in modo da far si che non rompano le balle!
    • daniele_dll _rosica scrive:
      Re: Ma perche' le salvano in chiaro?
      mmm, il problema non erano le password in chiaro o meno ma che venivano scritte nei log (il nome utente ci sta, ma la password?!?!?!)comunque il discorso password va preso con le pinze:- se ti serve avere le password non reversibili vai con un hash o un hmac-hash e sei tranquillo;- se ti serve la password reversibile allora la situazione è differente perché visto che il sistema informatico deve essere in grado di avere l'originale per operare sei punto accapo ... certo eviti che il ragazzino ottenga in chiaro le credenziali di acXXXXX, ma una volta che il sistema viene bucato a fare un bel tar della root (escludendo dev, proc, sys, tmp, var/tmp, var/run e via dicendo) e scaricarselo non ci vuole poi molto :)PS: mi sembra chiaro che in un contesto la cifratura rsa non serve visto che la chiave necessaria alla decodifica dovrebbe comunque essere presente sul server visto che serve in chiaro a luiPPS: per "servire in chiaro la password" intendo che possibilmente il software magari opera in un contesto in cui deve comunicare le credenziali ad un servizio esterno (verso un server interno o verso un altro server esterno alla rete) e quindi non si può fare molto (dipende dal sistema a cui si comunicano le credenziali ... ovviamente ci sono sempre delle possibilità ma se il sistema esterno non è adatto c'è poco che fare)PPPS: in questo caso è negligenza pura e basta :)- Scritto da: panda rossa
      Io non mi capacito di come ancora ci siano
      realta' che salvano le password in
      chiaro.

      Le password devono essere sempre criptate.

      E' assurdo che da qualunque parte vi sia un luogo
      con le password in
      chiaro.
      • panda rossa scrive:
        Re: Ma perche' le salvano in chiaro?
        - Scritto da: daniele_dll _rosica
        mmm, il problema non erano le password in chiaro
        o meno ma che venivano scritte nei log (il nome
        utente ci sta, ma la
        password?!?!?!)Venivano scritte nei log IN CHIARO!!!!Pure io ho delle applicazioni che richiedono autenticazione e scrivono nei log la password, ma gia criptata, cribbio!
        comunque il discorso password va preso con le
        pinze:
        - se ti serve avere le password non reversibili
        vai con un hash o un hmac-hash e sei
        tranquillo;
        - se ti serve la password reversibile allora la
        situazione è differente perché visto che il
        sistema informatico deve essere in grado di avere
        l'originale per operare sei punto accapo ...Quando mai serve una password non reversibile?Il proXXXXX di criptazione della password e' sempre non reversibile.Scrivi la password 12345Il sistema immediatamente la cripta con un hash non reversibile ahr34gres34e questo viene scritto nel log, e questo viene salvato su disco.Quando ti autentichi, il sistema cripta quello che scrivi e lo confronta col criptato. Se sono uguali, bene, altrimenti password errata.Gli algoritmi di hashing non reversibile sono presenti in tutte le librerie, e se proprio non li hai, prendi due numeri primi grossi, e te ne scrivi uno.
        certo eviti che il ragazzino ottenga in chiaro le
        credenziali di acXXXXX, ma una volta che il
        sistema viene bucato a fare un bel tar della root
        (escludendo dev, proc, sys, tmp, var/tmp, var/run
        e via dicendo) e scaricarselo non ci vuole poi
        molto
        :)E otterresti un bel file con gli hash invece delle password in chiaro, dei quali non ti fai niente perche' la criptazione e' irreversibile.
        PS: mi sembra chiaro che in un contesto la
        cifratura rsa non serve visto che la chiave
        necessaria alla decodifica dovrebbe comunque
        essere presente sul server visto che serve in
        chiaro a luiNon e' mica scritta in chiaro la chiave di codifica.
        PPS: per "servire in chiaro la password" intendo
        che possibilmente il software magari opera in un
        contesto in cui deve comunicare le credenziali ad
        un servizio esterno (verso un server interno o
        verso un altro server esterno alla rete) e quindi
        non si può fare molto (dipende dal sistema a cui
        si comunicano le credenziali ... Le password devono viaggiare criptate, se vuoi fare le cose fatte bene.Altrimenti c'e' sempre l'alternativa di fare le cose col XXXX, e poi siamo qui a piangere perche' qualcuno penetrando per sbaglio, trova migliaia di password in chiaro.
        ovviamente ci
        sono sempre delle possibilità ma se il sistema
        esterno non è adatto c'è poco che
        fare)Esistono policy di sicurezza che vanno rispettate.Se una procedura non rientra nelle policy di sicurezza aziendali, si va dal project manager e gli si spiega il problema.Ovviamente il sistemista bravo, solleva tale eventuale problema il giorno zero dell'analisi di progetto.Quello meno bravo lo solleva quando se ne rende conto (a.k.a. troppo tardi) e a quel punto la frittata e' fatta.
        PPPS: in questo caso è negligenza pura e basta :)Sommata ad una buona dose di inesperienza/idiozia.
        • sbrotfl scrive:
          Re: Ma perche' le salvano in chiaro?
          Scusa... quando intendi "inviare password criptate" (volevo quotarlo ma non avevo voglia di cercare il pezzo in tutta la trafila :P) intendi con SSL o qualcosa mi sfugge?
          • panda rossa scrive:
            Re: Ma perche' le salvano in chiaro?
            - Scritto da: sbrotfl
            Scusa... quando intendi "inviare password
            criptate" (volevo quotarlo ma non avevo voglia di
            cercare il pezzo in tutta la trafila :P) intendi
            con SSL o qualcosa mi
            sfugge?Aspetta, stai facendo confusione.Confondi la crittografia del dato con quella del protocollo di comunicazione.Lascia perdere il protocollo del quale non mi frega nulla.Parliamo del dato.L'utente scrive la password in chiaro e la invia al server.Si presume che la connessione tra client e server sia criptata di suo in questo segmento.Al server arriva la stringa contenente la password.L'applicazione lato server la trasforma in un hash asimmetrico.A quel punto la password inserita dall'utente in chiaro sparisce.Da li' in avanti c'e' l'hash asimmetrico.Facci quello che ti pare, salvalo, scrivilo nei log, twittalo.Con quello non ci fai comunque un tubo.
          • sbrotfl scrive:
            Re: Ma perche' le salvano in chiaro?
            - Scritto da: panda rossa
            - Scritto da: sbrotfl

            Scusa... quando intendi "inviare password

            criptate" (volevo quotarlo ma non avevo
            voglia
            di

            cercare il pezzo in tutta la trafila :P)
            intendi

            con SSL o qualcosa mi

            sfugge?

            Aspetta, stai facendo confusione.
            Confondi la crittografia del dato con quella del
            protocollo di
            comunicazione.
            Lascia perdere il protocollo del quale non mi
            frega
            nulla.
            Parliamo del dato.

            L'utente scrive la password in chiaro e la invia
            al
            server.
            Si presume che la connessione tra client e server
            sia criptata di suo in questo
            segmento.
            Al server arriva la stringa contenente la
            password.
            L'applicazione lato server la trasforma in un
            hash
            asimmetrico.
            A quel punto la password inserita dall'utente in
            chiaro
            sparisce.
            Da li' in avanti c'e' l'hash asimmetrico.
            Facci quello che ti pare, salvalo, scrivilo nei
            log,
            twittalo.
            Con quello non ci fai comunque un tubo.Si ma hai scritto "Le password devono viaggiare criptate, se vuoi fare le cose fatte bene." e questa parte non mi era chiara... ma se dici che intendi che la COMUNICAZIONE deve essere criptata, allora ok :).
      • xery scrive:
        Re: Ma perche' le salvano in chiaro?
        sbagli, anche se il servizio deve trasmettere la password ad un servizio esterno deve comunque inviare l'hash, in nessun caso la password deve essere in chiaro
    • Provare per credere scrive:
      Re: Ma perche' le salvano in chiaro?
      - Scritto da: panda rossa
      Io non mi capacito di come ancora ci siano
      realta' che salvano le password in
      chiaroTipo PI?
    • Guybrush scrive:
      Re: Ma perche' le salvano in chiaro?
      - Scritto da: panda rossa
      Io non mi capacito di come ancora ci siano
      realta' che salvano le password in
      chiaro.

      Le password devono essere sempre criptate.

      E' assurdo che da qualunque parte vi sia un luogo
      con le password in
      chiaro.Eppure, a prenderti in parola senza considerare il contesto, è proprio così: la password è sempre in chiaro, sempre disponibile, ben piazzata la', da qualche parte tra la sedia e il monitor.:-)GT
Chiudi i commenti